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1  Introduction 

This  report  provides  a  detailed  description  of  the  Ada/Xt  toolkit  architecture.  The  purpose 
of  this  report  is  to  describe  the  Ada/Xt  architecture  in  terms  of  system-independent  package 
specifications,  and  to  describe  the  analysis  which  contributed  to  major  design  decisions.  This 
report  is  part  1  of  a  two  part  Ada/Xt  design  description;  part  2  consists  of  the  compilable 
Ada  package  specifications  of  the  UR-20  Ada/Xt  implementation  which  conforms  to  the 
system-independent  specifications  outline  in  section  4  of  this  report. 

The  emphasis  on  system-independent  package  specifications  rather  than  language  inde¬ 
pendent  specifications  derives  from  recognition  that  the  C  language  interfaces  defined  in 
the  X  Toolkit  (Xt)  Intrinsics  definition  [3]  is  nearly  sufficiently  language  independent  -  for 
languages  in  the  Algol  tradition  (including  Ada).  The  Ada  toolkit  design  verifies  this  claim, 
since  there  is  a  very  close  syntactic  mapping  of  types  and  interfaces  from  the  Ada  specifica¬ 
tion  to  the  C  specification. 

The  difficult  problems  addressed  by  the  UR20-UI  design  effort  concerned  the  development 
of  object-oriented  toolkit  features  in  Ada.  This  area  of  toolkit  design  exposed  most  of 
the  language  dependencies  embedded  in  the  C  definition  of  Xt.  A  substantial  part  of  this 
report  discusses  the  effective  use  of  Ada  to  provide  object-oriented  features  (e.g.,  inheritance, 
procedure  types)  without  unduely  impacting  toolkit  performance  and  system  independence, 
and  without  relying  on  automatic  program  generation  techniques. 

Section  2  of  this  report  provides  a  high-level  description  of  the  MIT  X  Window  System, 
including  rationale  for  implementing  a  toolkit  in  Ada.  Section  3  discusses  the  UR20-UI  design 
goals,  approach,  and  a  detailed  analysis  of  the  key  design  decisions  made  concerning  the  im¬ 
plementation  of  object-oriented  toolkit  features.  Section  4  provides  the  system-independent 
toolkit  specification.  The  organization  of  section  4  parallels  exactly  the  MIT  X  Toolkit  In¬ 
trinsics  document  all  [3]  Indeed,  most  operations  defined  in  section  4  are  not  documented 
in  this  report;  instead,  the  MIT  documentation  is  referenced.  This  demonstration  of  toolkit 
similarity  is  an  important  result  of  the  UR20-UI  approach,  and  should  facilitate  MIT  X 
Consortium  acceptance  of  the  STARS  Ada/Xt  toolkit  for  eventual  Consortium  maintenance 
and  distribution. 


2  Overview  of  the  X  Window  System 

This  section  of  the  report  provides  a  brief  description  of  the  X  Window  System,  and  intro¬ 
duces  and  defines  terminology  used  throughout  this  report.  A  more  complete  description  of 
X  can  be  found  in  [6]. 

X  is  a  network-based  windowing  system.  The  National  Institute  for  Standards  and  Tech¬ 
nology  (NIST)  has  developed  a  layered  model  to  describe  user  interface  architectures.  This 
layered  model  is  depicted  in  figure  1,  and  has  become  a  federal  information  processing  stan- 
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2  OVERVIEW  OF  THE  X  WINDOW  SYSTEM  5 

dard  (FIPS)  [4].  The  lower  four  layers  of  this  model  in  effect  provide  a  description  of  the  X 
Window  System. 

The  lowest  layer  in  the  model,  layer  0,  is  the  X  protocol.  This  data-stream  protocol  for  X 
is  currently  undergoing  formal  standardization  efforts  in  the  ANSI  X3H3.6  committee.  The 
protocol  defines  the  manner  in  which  X  applications  communicate  with  X  servers.  Applica¬ 
tions  in  this  sense  are  sometimes  called  clients,  although  thi6  terminology  may  be  confusing 
because  the  term  “client”  is  also  used  to  describe  user's  of  toolkit  widgets  (described,  below). 

The  next  layer,  layer  1,  is  the  programmatic  interface  to  the  protocol  layer.  This  set 
of  interfaces,  known  collectively  as  “Xlib”,  provides  the  primitive  programmatic  layer  upon 
which  X  applications  can  make  requests  of  X  servers.  SAIC,  under  a  STARS  Foundations 
contract,  developed  Ada  bindings  to  the  C  Xlib  implementation.  This  set  of  bindings  can  be 
characterized  as  (moderately)  “deep”  bindings,  since  a  substantial  effort  was  made  to  map 
the  C  data  types  to  Ada,  and  do  as  much  Xlib  processing  in  Ada  as  possible  before  sending 
the  actual  request  to  the  C  implementation. 

The  Ada/Xlib  bindings  were  not  complete,  however.  Utility  functions  requiring  proce¬ 
dure  types  as  parameters  were  not  implemented,  probably  because  any  implementation  of 
procedure  types  that  would  enable  C  Xlib  code  to  execute  Ada  subprograms  was  deemed 
to  be  too  system-dependent  for  STARS.  Resource  management  was  also  not  implemented. 
The  reason  why  these  interfaces  were  not  mapped  in  the  Ada  bindings  is  not  clear,  although 
it  is  possible  that  these  interfaces  were  not  officially  part  of  the  Xlib  layer  at  the  time  the 
foundations  work  began. 

The  next  two  layers,  layers  2  and  3,  map  to  the  MIT  Toolkit  intrinsics  and  widgets 
layers,  respectively.  The  Unisys  UR20  user  interface  subtask  addresses  the  development  of 
an  Ada  implementation  of  these  two  layers  -  not  bindings.  These  Ada  implementations  will 
make  use  of  the  SAIC  Xlib  bindings,  which  have  been  upgraded  to  revision  3  (X11R3),  and 
extended  to  include  all  of  the  Xlib  resource  management  functions,  as  part  of  the  UR20  task. 

Layer  2,  the  subroutine  foundation  layer,  defines  a  single  application  portability  interface 
(API)  for  manipulating  collections  of  U6er  interface  abstractions  (called  “toolkit  in  the 
reference  model,  but  called  “widgets”  or  “widget  sets”  in  Xt  parlance).  This  separation 
of  subroutine  interface  from  user  interface  abstraction  presents  interesting  programming 
paradigm  questions  to  Ada  software  developers.  That  is,  the  intrinsics  (layer  2)  define  a 
set  of  interfaces  for  manipulating  an  open-ended  set  of  abstractions.  As  will  be  discussed 
later  in  this  report,  Ada  generics  are  not  sufficiently  general  to  support  this  kind  of  software 
layering. 

Layer  3,  the  toolkit,  is  essentially  a  library  of  reusable,  extensible,  and  composable  user 
interface  abstractions.  This  “widget”  library  provides  an  excellent  example  of  what  Unisys 
has  been  describing  as  tool  fragments ,  here  tailored  to  the  fragments  of  tools  which  concern 
the  display  of  application  program  data.  The  ideas  of  widget  reusability,  extensibility  and 
composability  are  central  to  the  MIT  X  Toolkit,  or  “Xt”,  which  draws  heavily  upon  the 
concepts  of  object-oriented  programming  languages  and  systems  in  order  to  achieve  these 
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Layer  6:  Application 


Layer  5:  Dialogue 

(UIMS ,  Window  Mgr.) 


Layer  4:  Presentation 

(UIMS,  Window  Mgr.) 


Layer  3:  Toolkit 


Layer  2:  Subroutine  Foundation 


Layer  1:  Data  Streaa  Interface 


Layer  0:  Data  Streaa  Encoding 


Figure  1:  NIST  User  Interface  Reference  Model 
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effects.  A  significant  part  of  this  design  report  addresses  the  simulation  of  object-orientation 
in  Ada  without  recourse  to  program  generation. 

2.1  X  and  Industry  Standardized  API 

In  recent  years  the  industry  has  recognized  the  importance  of  separating  the  user  interface 
code  and  the  application  code.  This  separation  reduces  software  development  costs  by  per¬ 
mitting  reuse  of  user  interface  code  and  providing  consistent  behavior  (reducing  training 
costs  and  reducing  errors  caused  by  differences  in  the  user  interface  behavior).  This  separa¬ 
tion  requires  a  well  defined  interface  between  the  application  and  user  interface  abstractions, 
called  an  application  program  interface  or  API. 

In  X  the  interface  to  the  user  interface  abstractions  or  widgets  consists  of  functions 
(contained  in  the  intrinsics)  to  access  widgets  and  the  data  structures  within  the  widgets  that 
allow  applications  to  customize  the  user  interface.  These  data  structures  contain  resources 
(specifying  color,  size,  fonts,  etc.)  and  lists  of  application  procedures  invoked  by  the  intrinsics 
upon  occurrence  of  specified  events. 

Why  is  the  industry  demanding  a  standard  API  and  user  interface  abstractions?  The 
demand  originates  in  the  user  community  (especially  the  U.  S.  government)  and  independent 
software  vendors  (ISVs).  Users  now  buy  hardware  platforms  and  software  from  a  variety  of 
vendors  and  need  a  consistent  user  interface  (ulook  and  feel”  or  appearance  smd  behavior) 
across  platforms  and  among  applications  running  on  a  single  platform. 

ISVs  face  a  demand  for  their  applications  on  a  variety  of  platforms.  The  application 
changes  little  from  platform  to  platform,  but  the  user  interface  may  change  drastically.  The 
separation  of  the  user  interface  from  the  application  is  important,  so  that  a  port  to  another 
platform  requires  at  most  a  rewrite  of  the  user  interface  and  not  a  complete  rewrite  of 
the  application.  Furthermore,  a  common  API  means  the  application  code  need  not  change 
when  the  user  interface  changes.  Portable  user  interface  abstractions  like  the  Xt  widgets 
mean  that  an  ISV  can  easily  port  a  user  interface  from  platform  to  platform,  thus  reducing 
the  conversion  costs  smd  ensuring  a  consistent  “look  and  feel”  across  all  platforms,  and 
consistency  among  the  ISV’s  product  user  interfaces. 

Industry  standards  organizations,  ANSI  X3  and  IEEE,  are  standardizing  the  lower  layers 
of  the  FIPS  model.  The  X  protocol  (data  stream  encoding)  standards  work  began  two  years 
ago  and  should  be  completed  soon  by  X3H3.6.  The  toolkit  and  API  standardization  work 
began  in  1989  in  the  IEEE  P1201  committee.  P1201  is  currently  working  on  a  standard  for 
the  widget  set.  ANSI  X3V1  is  working  on  standards  for  man-machine  interfaces.  X3V1.9 
will  develop  standards  for  “look  and  feel”  of  user  interface  abstractions  such  as  menus. 

Why  has  NIST  and  the  standards  bodies  chosen  X?  X  is  the  first  widely  accepted  window 
system  addressing  the  needs  of  the  networked,  bit-mapped  graphics  workstation  environment. 
X  runs  on  a  wide  range  of  Unix  based  platforms,  Digital  VMS  and  Ultrix  machines,  IBM 
mainframes,  Apple  Macintosh,  PCs  and  graphics  terminals.  One  reason  for  its  acceptance  is 
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2  OVERVIEW  OF  THE  X  WINDOW  SYSTEM  8 

that  source  is  available  free  of  licenses  or  royalties.  In  addition,  interfaces  to  several  languages 
exist,  C  (primarily),  C++,  Lisp,  Ada,  and  Prolog;  however  not  all  implementations  support 
the  Xt  toolkit  layer. 

2.2  X  Toolkits  and  the  MIT  X  Toolkit  “Xt” 

A  number  of  toolkits  evolved  from  the  X  Window  System.  Most  of  these  are  based  on 
the  Xt  intrinsics.  MIT  released  a  sample  set  of  widgets,  Athena  widgets,  with  the  Xt 
Intrinsics,  and  many  applications  were  and  still  are  being  written  using  Athena  widgets. 
The  Athena  widgets  were  an  incomplete  set  (there  is  no  menu  widget;  one  can  be  built  from 
other  Athena  widgets),  and  so  various  companies  added  widgets  to  their  X  based  products. 
Digital  developed  XUI,  AT&T  Xt+,  and  HP  and  Sony  developed  widget  sets.  In  many  cases 
(XUI  and  Xt+)  the  intrinsics  were  extended.  With  the  demand  for  a  single  API  and  “look 
and  feel”  from  users  and  ISVs,  groups  like  the  Open  Software  Foundation  (OSF)  moved 
toward  a  single  API  and  widget  set.  OSF  developed  Motif  by  merging  XUI  and  the  HP 
widget  set.  There  is  still  not  an  agreement  on  a  single  widget  set,  but  the  standards  work 
will  eventually  define  one. 

Most  toolkits  are  based  on  the  MIT  Xt  Intrinsics,  but  several  are  not:  Xray  [2],  Andrew 
[5]  and  XView  are  well  known  examples.  Xray  (or  Xrlib)  was  an  early  HP  toolkit  which 
added  three  layers  above  the  Xlib  layer: 

•  Intrinsics  -  input  handling,  object  interaction  and  geometry  management, 

•  Field  Editors  -  the  basic  user  interface  abstractions  such  as  scrollbars  and  buttons, 

•  Dialogs  -  higher  level  abstractions  such  as  menus,  message  boxes  and  panels. 

With  the  rising  popularity  of  Xt,  HP  implemented  a  similar  “look  and  feel”  with  an  Xt 
Intrinsics  based  widget  set  and  use  of  Xray  has  declined. 

Sun  recently  announced  the  release  of  XView,  a  toolkit  built  upon  the  Xlib  layer.  The 
XView  API  is  compatible  with  the  proprietary  SunView  API.  XView  implements  the  Sun/ AT&T 
Open  Look  “look  and  feel”. 

The  Andrew  Toolkit,  developed  at  Carnegie  Mellon  University  (CMU),  is  a  window 
system  independent,  object  oriented  toolkit.  Besides  a  CMU  built  window  system,  the 
Andrew  Toolkit  supports  X  (X  protocol  and  Xlib).  The  Andrew  Toolkit  consists  of  data 
object/view  pairs  where  the  data  object  is  the  information  to  be  displayed  (text  in  a  text 
editor,  for  example)  and  a  view  is  the  user  interface  abstraction  (scrollbars,  menus,  etc). 
One  feature  of  Andrew  is  the  ability  to  intersperse  multiple  data  objects  within  a  view.  This 
permits  a  mixture  of  text,  graphics  and  animations  within  a  window  (e.g.  animation  and 
graphics  can  occur  along  with  text  in  the  body  of  an  email  message).  This  toolkit  has  not 
been  widely  accepted  beyond  CMU. 
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Xt  is  clearly  the  dominant  toolkit  in  the  marketplace.  What  are  the  features  that  are 
making  Xt  the  de  facto  standard  and  soon  an  official  standard?  Certainly,  its  availability 
free  of  licenses  and  royalties  is  a  contributing  factor.  Other  important  attractions  are  its 
extensibility  through  creation  of  new  widgets,  and  from  its  object  oriented  design  and  the 
ability  to  easily  subclass  widgets.  Adding  new  widgets  or  subclassing  does  not  require 
recompilation  of  the  toolkit  since  the  intrinsics  do  not  need  to  know  anything  about  a 
specific  widget.  The  intrinsics  are  policy  free  (implies  nothing  about  “look  and  feel”)  so  that 
a  vendor  or  application  is  free  to  specify  its  own  “look  and  feel”  by  choice  of  widgets.  Xt  also 
provides  the  separation  of  user  interface  objects  from  the  application  code,  thus  permitting 
portability  and  reuse  of  the  user  interface  code. 

2.3  Why  an  Ada  Implementation  of  Xt? 

Implementing  Xt  in  Ada  presents  some  challenging  problems,  and  is  not  without  some  risk. 
To  achieve  a  high  degree  of  flexibility  and  extensibility,  Xt  made  use  of  language  features 
which  have  only  tenuous  analogs  in  Ada  (e.g.,  procedure  types).  Finding  the  correct  Ada 
approach  to  these  language  dependent  features  of  Xt  requires  making  tradeoffs  among:  com¬ 
piler  independence,  operating  system  independence,  and  sy stem /hardware  independence. 
Choosing  a  suboptimal  Ada  design/implementation  risks  industry  acceptance  of  Ada/Xt, 
and  hence  risks  emergence  of  a  de  facto  Ada  toolkit  API.  However,  in  many  cases,  no  “per¬ 
fect”  solution  exists.  In  fact,  a  significant  portion  of  this  report  deals  with  the  tradeoffs 
among  various  competing  implementation  strategies. 

Since  a  fairly  substantial  engineering  effort  must  be  expended  (with  some  risk)  to  imple¬ 
ment  Xt  in  Ada,  a  reasonable  question  to  ask  is  whether  a  better  cost /benefit  ratio  would 
be  obtained  by  following  the  Ada/Xlib  example  and  developing  an  Ada  binding  to  the  MIT 
X  toolkit.  There  are  several  reasons  why  a  bindings  approach  to  Xt  would  not  be  adequate 
in  the  long-term. 

First,  there  is  the  issue  of  widget  set  extensibility.  A  significant  feature  of  the  Xt  model 
is  the  ease  with  which  new  widgets  can  be  constructed  from  old  widgets.  Indeed,  this  is 
a  hallmark  of  object-oriented  programming  in  general,  which  attempts  to  maximize  reuse 
by  factoring  abstractions  into  class  hierarchies,  facilitating  finer-grained  reuse  than  possible 
with  unstructured  collections  of  monolithic  abstractions.  However,  a  set  of  bindings  to  the  C 
implementation  of  Xt  would  require  that  new  widgets  be  programmed  in  C,  and  that  a  fairly 
elaborate  system-dependent  type  mapping  interface  be  developed  and  maintained  which 
maps  Ada  application  resource  types  to  the  underlying  C  representations  for  management 
by  the  C  toolkit  implementation. 

Second,  beside  issues  of  static  inter-language  interfaces,  there  are  issues  of  inter-language 
runtime  cooperation.  The  notion  of  procedure  reference  is  indelible  in  Xt:  a  major  part  of 
the  toolkit  model  is  that  the  toolkit  will  execute  application  code  on  behalf  of  the  application 
in  response  to  certain  events  generated  by  the  server.  That  is,  an  Xt  application  program 
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does  not  have  &  traditional  control  structure,  but  rather  specifies  what  code  to  execute 
under  various  circumstances:  the  toolkit  in  effect  executes  the  application  program.  As  a 
consequence,  a  toolkit  binding  needs  to  provide  the  C  implementation  with  the  addrtss  of  a 
subprogram  which  will  execute  Ada  code  (either  directly  or  indirectly).  This  introduces  a 
considerable  degree  of  compiler  dependence,  since  the  details  of  parameter  passing  protocol 
and  stack  frame  environments  are  not  specified  by  the  Ada  language  definition.  Although 
the  UR20  toolkit  implementation  makes  use  of  procedure  addresses,  it  provides  an  interface 
which  will  accommodate  a  “pure  Ada”  solution  should  circumstances  demand  it.  An  Ada 
binding  to  Xt  would  not  have  this  luxury. 

Finally,  there  are  issues  of  runtime  environment  interaction.  If  a  significant  number  of 
Ada  applications  are  to  be  developed  which  use  the  X  Window  System,  issues  of  conflict 
between  the  Ada  runtime  system  and  underlying  host  operating  system  must  be  considered. 
For  example,  conflicts  between  the  Ada  runtime  envirc~*"ient  usage  of  Unix  signals  to  control 
task  scheduling  and  C  Xlib  code  must  be  carefully  cc  .dered.  Some  Ada  runtime  environ¬ 
ments  even  provide  a  mechanism  to  disable  runtime  environment  signal  usage  during  calls 
to  external  language  routines.  This  added  complexity  and  system  dependency  can  only  be 
adequately  resolved  if,  in  the  long  term,  a  full  Ada  implementation  of  the  client  interfaces 
to  X  is  developed  (Xlib  and  toolkit  interfaces).  From  this  perspective,  the  development  of 
another  Ada  binding  would  be  at  most  a  stopgap  effort  which  would  have  to  be  redone  at  a 
later  date. 


3  Design  Approach 

The  UR20  task  had  two  overriding  goals  to  achieve  in  the  Ada  toolkit  implementation: 

•  Develop  an  eminently  usable  implementation  of  Xt  which  fully  preserves  the  features 
and  advantages  of  the  C  implementation. 

•  Establish  that  the  Ada  implementation  faithfully  implements  the  MIT  toolkit,  and 
achieve  X  Consortium  acceptance  of  the  Ada  implementation  as  a  Consortium  “prod¬ 
uct.” 

The  first  goal  does  not  strictly  require  implementing  Xt,  but  rather  some  toolkit  which 
provides  all  of  the  features  that  Xt  provides.  In  practice  however,  it  would  be  unreasonable  to 
expect  to  design  and  implement  an  entirely  new  toolkit  model  (in  a  nine  month  performance 
period)  which  can  compete  with  Xt.  Instead,  this  goal  had  more  to  do  with  ensuring  that 
the  resulting  implementation  of  Xt  sufficiently  preserves  the  strictures  of  Ada  style  and 
usage,  and  was  also  efficient  and  compact  so  as  not  to  overburden  applications  which  require 
interactive  windowing  interfaces.  In  short,  this  goal  concerns  acceptance  of  Ada/Xt  by  Ada 
software  practitioners. 
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The  second  goal  requires  presentation  to  the  X  Consortium  of  some  evidence  that  the 
Ada  implementation  faithfully  implements  the  MIT  X  Toolkit.  This  presented  an  interesting 
question,  since  the  only  existing  description  of  what  Xt  is  is  a  very  detailed  description  of 
the  C  implementation.  That  is,  there  is  no  pre-existing  specification  of  what  Xt  is  beyond 
it's  implementation.  This  goal,  then,  concerns  provision  of  an  architectural  description  of 
the  Ada  implementation  which  will  maximize  our  chances  of  attaining  acceptance  of  Ada/Xt 
by  X  Consortium  members. 

Note:  This  section  of  the  design  report  provides  an  in*depth  discussion  of 
various  approaches  to  implement  Xt  in  Ada.  In  places,  understanding  the  highly 
detailed  discussion  of  advanced  Ada  programming  techniques  used  in  Ada/Xt 
requires  that  the  reader  has  a  significant  degree  of  Ada  and  MIT  X  Toolkit 
competency. 

3.1  Functional  Specifications  and  Re-Engineering 

The  originally  stated  UR20-UI  toolkit  design  approach  was  to  begin  with  a  study  of  the  MIT 
Xt  implementation  and  documentation,  and  from  this  study  extract  and  specify  a  language 
independent  specification  of  the  MIT  X  Toolkit.  This  specification  would  then  be  mapped  to 
some  Ada  realization.  Thus,  two  products  of  this  design  process  were  envisioned:  a  language 
independent  specification,  and  an  Ada  language  specification,  of  Xt. 

However,  this  abstract  process  encountered  difficulties  early  on.  It  became  apparent  that 
there  was  very  little  that  was  indeed  "language  independent”  in  the  C  documentation.  Fur¬ 
ther,  we  began  to  suspect  that  what  truly  did  constitute  language  independent  architectural 
constraints  would,  when  specified,  provide  little  or  no  insight  to  the  task  of  creating  an  Ada 
implementation.  Thus,  our  premise  that  a  language  independent  model  could  be  extracted 
via  a  reengineering  process  seems  faulty. 

For  example,  consider  the  issue  of  widget  subclassing  and  inheritance.  The  C  imple¬ 
mentation  supports  subclassing  and  inheritance  via  manual  type  conversions  to  predefined, 
known  widget  and  widget-class  data  structures,  and  data  structure  specification  conventions, 
respectively.  This  is  a  concrete  realization  of  the  abstract  idea  of  widget-clas6  hierarchies 
with  inheritance.  The  realization  of  this  abstract  architectural  feature  in  an  object-oriented 
language  like  C++  or  CLOS  will  likely  be  radically  different  from  the  C  realization;  a 
language-independent  specification  sufficiently  general  to  describe  these  various  implemen¬ 
tations  would  be  vague  to  the  point  of  being  useless  as  a  prescriptive  vehicle. 

This  may  appear  to  be  a  disappointing  result,  but  there  are  positive  aspects.  First, 
we  concluded  that  a  truly  language  independent  specification  is  not  likely  to  be  of  much 
use  beyond  shallow  conformance  testing.  However,  the  Xt  implementation  does  provide 
an  approach  for  implementing  an  object-oriented  system  in  non-object-oriented  languages. 
More  specifically,  we  were  able  to  test  the  assertion  made  by  the  author’s  of  Xt  that  the 
intrinsics  are  language  independent  for  procedural  languages. 
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We  conclude  that  they  are  indeed  reasonably  language  independent  for  procedural  lan¬ 
guages  in  the  Algol-Pascal-Modula2-Ada  tradition.  Further,  modulo  minor  syntactic  varia¬ 
tions  (e.g.,  turning  C  functions  with  6ide-effects  into  Ada  procedures),  an  Ada  implementa¬ 
tion  of  Xt  is  able  to  preserve  a  very  direct  syntactic  mapping  of  Ada  intrinsics  to  C  intrinsics, 
and  Ada  widget  programming  conventions  to  C  widget  programming  conventions.  This  is 
indeed  an  excellent  result  because  it  provides  in  effect  what  we  wanted  from  the  language- 
independent  specification:  some  means  to  justify  to  the  X  Consortium  that  we  had  imple¬ 
mented  the  MIT  X  Toolkit,  and  not  some  new  variant.  Further,  this  close  correspondence 
is  a  compelling  argument  for  tying  evolution  of  the  Ada  implementation  to  it’s  “parent” 
C  implementation,  since  the  differences  are  not  so  great  as  to  make  parallel  evolution  an 
unreasonably  expensive  venture. 

Although  UR20-UI  does  not  provide  a  language  independent  specification  for  Xt,  we  do 
provide  a  system-independent  Ada  specification,  suitable  as  a  basis  for  standardization  in 
the  Ada  community.  This  specification  is  useful  for  highlighting  where  extra  implementation 
details  may  be  added  to  support  implementation  on  a  particular  hud  ware/operating  system 
platform. 

3.2  Object- Orientation  in  Ada/Xt 

It  is  not  the  purpose  of  this  design  report  to  convince  the  reader  of  the  utility  of  object- 
oriented  programming  in  the  development  of  user  interface-intensive  systems.  This  report 
also  assumes  some  level  of  familiarity  with  such  terms  as  object  class ,  object  instance ,  and 
inheritance.  Description  of  object-oriented  concepts  are  numerous  in  literature,  of  which 
[1,  7]  are  just  a  small  (but  significant)  portion. 

Three  features  of  object-oriented  languages  need  to  be  simulated  in  Ada  before  an  ad¬ 
equate  implementation  of  Xt  can  be  undertaken.  The  design  of  this  simulation  using  Ada 
features,  rather  than  through  some  form  of  program  generation,  constituted  a  significant 
portion  of  the  Ada/Xt  design  process.  These  three  features  are: 

•  subprogram  types ,  i.e.,  “methods” 

•  inheritance 

•  polymorphism 

It  is  important  to  note  the  term  simulation.  The  ideas  of  runtime  type  polymorphism 
and  type  inheritance  introduces  a  model  of  type  semantics  not  implemented  by  Ada  (or  C). 
Since  Ada  does  not  implement  the  type  model  required  of  an  object  oriented  system,  this 
type  model  must  be  simulated.  Thus,  one  way  of  viewing  the  toolkit  architecture  is  as  a 
system  of  programmatic  interfaces  and  programming  conventions  to  use  these  interfaces  in 
order  to  simulate  object-oriented  capabilities  in  a  non-objective  language. 
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The  remainder  of  this  section  describes  how  the  Ada/Xt  architecture  simulates  subpro¬ 
gram  types,  inheritance,  and  polymorphism. 


3.3  Simulating  Subprogram  Types  in  Ada 

This  section  describes  various  solutions  to  the  problem  of  simulating  subprogram  types  in 
Ada.  It  is  important  to  note  that  the  problem  being  solved  is  not  simply  that  of  referring  to 
executable  code  as  data.  Were  that  the  case,  the  Ada  tasking  mechanism  would  be  sufficient 
(albeit  somewhat  an  overkill).  Instead,  the  problem  is  one  of  referring  to  subprograms  as 
types  characterized  by  interface  alone,  such  that  two  subprograms  with  the  same  interface 
but  that  compute  distinct  functions  would  be  considered  subprograms  of  the  same  type. 

S.S.l  Task  Types  and  Unchecked  Conversion 

One  implementation  approach  makes  use  of  Ada  task  types  as  a  foundation  for  implementing 
subprogram  types.  Unfortunately,  task  types  do  not  provide  for  alternative  task  bodies  for 
task  specifications. 

One  way  around  this  is  to  define  a  task  type  TO  with  a  task  entry  Te  whose  parameter 
profile  matches  the  subprogram  profile  type  being  implemented.  Rendezvous  with  instances 
of  TO  on  entry  Te  will  raise  an  exception  -  task  type  TO  is  merely  used  in  order  to  create  a 
type  mark  for  constructing  a  data  structure  containing  references  to  other  task  types  which 
share  the  same  syntactic  task  specification.  New  task  types  Tn,  Tm,  Tp  can  be  defined 
which  have  the  same  syntactic  specification  as  TO,  and  instances  of  these  new  task  types 
can  be  type  converted  (via  Ada  unchecked-conversion)  to  instances  of  type  TO.  Finally,  the 
entries  of  Tn,  Tm,  and  Tp  are  accessed  via  rendezvous  with  these  task  instances  as  if  they 
were  instances  of  TO.  Thus,  uncheckedjconversion  is  used  to  achieve  distinct  task  bodies  for 
the  same  task  specification. 

However,  this  implementation  was  rejected  for  two  reasons.  First,  although  thi6  technique 
worked  on  several  compilers,  this  use  of  unchecked  conversion  is  clearly  outside  the  scope 
of  the  intended  use  of  thi6  feature.  There  is  no  reason  to  believe  that  all  compiler  vendors 
will  generate  code  to  perform  rendezvous  based  solely  upon  the  syntactic  form  of  the  task 
definition.  Although  we  do  endorse  some  level  of  system-dependent  programming  for  Ada 
implementations  of  the  X  toolkit,  this  kind  of  systems- dependent  programming  must  be 
considered  dangerous. 

A  second  reason  for  disqualifying  this  technique  derives  from  practical  constraints  im¬ 
posed  upon  the  UR20  approach.  That  is,  UR20  takes  as  a  foundational  basis  the  STARS 
Foundations  Ada/Xlib  bindings.  Thus  a  significant  amount  of  application  processing  is  ac¬ 
tually  done  by  code  written  in  C.  However,  the  use  of  tasking  introduces  many  potential 
conflicts  between  the  Ada  runtime  environment  and  the  underlying  host  operating  system, 
which  is  accessed  directly  by  the  C  implementation  of  Xlib.  In  particular,  Ada  runtime  en- 
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generic 

type  gen.widget  it  private; 
type  gen.widget. class  is  private; 

—  core  class  procedures  needed  during  widget  creation 
with  procedure  class_part_initialize(wc  :  widget.class) ; 
with  procedure  class. initialize; 

with  procedure  initialize(request,  new.request  :  widget); 
with  procedure  initialize.hookCw  :  widget; 

ergs  :  arg.list); 

—  creates  the  widget  record  with  proper  size 
with  function  malloc.widget  return  gen.widget; 

package  create  is 

function  ztcreatewidget(naae  :  string; 

widget.class.ptr  :  gen. widget. class; 

parent  :  widget; 

ergs  :  arg.list)  return  widget; 

end  create; 


Figure  2:  Generic  Widget  Creation  Specification 

vironment  use  of  Unix  signals  as  a  means  of  task  scheduling  (e.g.,  SIGALARM)  can  conflict 
with  the  smooth  execution  of  C  code  depending  upon  Unix  interprocess  communication. 

3.3.2  Ada  Generics 

Another  approach  to  handling  procedure  types  is  through  the  use  of  Ada  generics  to  pa¬ 
rameterize  widget  class  definitions  with  the  class  operations  that  would  be  otherwise  rep¬ 
resented  as  procedure  type  instances  embedded  in  the  widget  class  data  structures  (these 
data  structures  sure  described  in  greater  detail  later  in  this  report).  Although  this  static 
parameterization  would  not  apply  to  more  dynamic  use6  of  procedure  types  (e.g.,  callback 
resources),  generic  parameterization  of  static  subprogram  types  would  constitute  a  signifi¬ 
cant  design  decision  for  the  Ada/Xt  toolkit.  We  tried  this  with  the  procedure  types  in  the 
core  class  record  structure.  These  procedures  handle  initializations,  setting  and  retrieving 
resource  values,  resizing,  exposures,  etc.  We  thought  certain  functional  areas,  such  as  widget 
creation,  could  be  defined  by  generics  and  instantiated  with  the  needed  functions  defined  in 
the  core  class.  To  minimize  the  size  of  the  generics  we  attempted  to  write  the  generics  as  a 
thin  generic  interface  which  references  underlying,  non-generic  widget  creation  code. 

The  code  fragment  in  figure  2  is  the  generic  specification  for  widget  creation  code.  The 
code  fragment  in  figure  3  is  an  instantiation  of  the  generic  specification  for  label  widget 
creation. 

Some  of  the  core  class  procedure  types  were  only  invoked  within  superclass  to  subclass 
chains  and  could  be  implemented  as  generics  parameterized  by  the  core  class  function  and 
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packag*  label  it 

packaga  labal.craata  it  ntv  craata(label_widg«t, 

labtl.vidgat.claii , 
class.part.init , 
elatt.initializa, 
init, 

ini t .book, 

malloc.label.widget) ; 

•nd  label; 


Figure  3:  Generic  Widget  Creation  Instantiation 

its  superclass  instantiation  of  the  same  chaining  generic.  The  code  fragment  in  figure  4  is 
the  superclass  to  subclass  chaining  generic  for  the  claaa.part.initialize  function  specified  in 
the  core  data  of  every  widget  class. 

Finally,  The  code  fragment  in  figure  5  instantiates  the  claaa. part. init  superclass-to- 
subclass  chain  for  the  label  widget.  Note,  the  label  widget  does  not  execute  an}'  code  for 
c/ass  part  initialization  and  a  dummy  procedure  (with  empty  body)  is  used  to  instantiate 
the  generic. 

Although  we  demonstrated  the  use  of  generics  for  procedure  types  in  the  proof-of- concept 
for  widget  creation,  we  exposed  a  number  of  inadequacies  in  the  approach. 

We  realized  that  this  approach  would  require  a  large  number  of  generic  instantiations 
for  each  widget  class  used  in  an  application.  We  hoped  that  the  generics  would  be  a  thin 
interface  to  the  intrinsics,  but  the  widget  creation  generic  showed  that  references  to  generic 
parameters  were  needed  throughout  the  widget  creation  code.  We  concluded  that  generic 
Ada  packages  to  simulate  procedure  types  require  virtually  complete  implementation  of  the 
intrinsics  within  generics,  thus  forcing  applications  to  instantiate  a  copy  of  the  intrinsics  for 
each  widget  class  used  in  the  application. 

Simulating  procedure  types  with  generics  failed  to  handle  all  use6  of  procedure  types 
in  the  intrinsics.  Our  method  worked  because  the  procedures  were  determined  at  compile 
time  and  based  on  a  static  tree  structure  (the  widget  claaa  hierarchy).  This  failed  on  dy¬ 
namic  structures  such  m  the  run  time  widget  tree.  The  generic  approach  failed  in  widget 
creation  when  calling  the  widget’s  parent’s  insert-child  procedure.  The  generic  instantiation 
of  XtCreateWidget  can  not  know  anything  about  the  parent’s  inaert.child  procedure.  Pro¬ 
cedure  types  referenced  via  dynamic  structures,  such  as  the  widget  tree,  require  a  different 
approach. 

The  expected  code  size  due  to  the  large  number  and  6ize  of  generic  instantiations  and 
the  failure  of  the  generic  approach  for  simulating  some  procedure  types  made  this  approach 
unacceptable. 
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package  intrinsic*  is 

—  superclass  to  subclass  chaining  generics 
generic 

vith  procedure  superclass. class.part.init (class  :  widget.class); 
with  procedure  class_part_initialize(class  :  widget. class) ; 
procedure  class.part.init.chainCclass  :  widget.class) ; 
end  intrinsic*; 

package  body  intrinsic*  is 

procedure  class.part.init.chainCclass  :  widget.class)  is 
*-  class .part .initialize  is  a  downward  chaining  procedure 
class.ptr  :  core.class  :■  widget.to.core.class(class) ; 
begin 

if  class.ptr. core.class. superclass  /■  null.address  then 

superclass. class.part.init (class.ptr. core.class .superclass) j 
end  if ; 

if  class.ptr. core.class .class.part. initialize  then 
class.part. initialize (class) ; 
end  if; 

end  class.part. init.chain; 
end  intrinsics; 


Figure  4:  Generic  Superclass-Subclass  Chaining 


package  label  is 

label.core.part  :  core.class.part  :• 

(superclass  «>  superclass_to_widget_class(sinple_classrec_ptr) , 

class .nan*  ■>  "label", 

widget. size  ■>  labelrec’size, 

class. initialize  ■>  true, 

class.part.initializ*  •>  false, 

—  remaining  fields  follow 

); 

—  downward  chaining  functions 

—  renames  the  label  widget's  superclass  class.part.init  function 

procedure  sup*rclass_class_part_init(class  :  widget.class) 

renames  simple. class.part.init; 

—  the  label  widget's  class.part.init  function  is  null  so  instantiate 

—  the  generic  with  the  superclass’s  and  a  dummy  label  class.part.init 

procedure  class.part.init  is 

new  class.part.init. chain(sup*rclass. class.part.init , 

null.class.part.initialize) ; 

end  label; 


Figure  5:  Generic  Superclass-Subclass  Instantiation 
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3.S.3  Cascading  Generics  and  Case  Statement  Simulation 

Although  Ada  does  not  provide  for  procedure  types  (from  which  reference  types  can  be 
constructed),  it  is  still  possible  to  simulate  procedure  types  in  a  system-independent  manner. 
The  simple  scheme  is  to  assign  a  unique  identifier  to  subprograms,  and  use  this  identifier  as 
an  index  to  an  Ada  case  statement  which  invokes  the  subprograms.  The  only  difficulty  that 
needs  to  be  addressed  in  this  implementation  is  how  these  unique  identifiers  are  generated. 

In  a  Q-task  standards  report  [8]  Unisys  proposed  one  implementation  which  uses  the 
Ada  generics  mechanism  to  generate  procedure  references.  The  package  specification  for  this 
implementation  is  provided  in  figure  6.  The  full  implementation  is  provided  for  convenience 
in  appendix  A. 

This  implementation  makes  use  of  cascaded  generic  instantiations  to  in  effect  create  a 
linked-list  of  generated  (via  instantations)  package  bodies.  Each  generated  package  body 
acts  as  a  state  machine  which  manages  a  discrete  range  of  subprogram  indexes;  indexes  that 
lie  outside  this  range  indicate  that  the  actual  subprogram  referenced  by  the  index  is  managed 
by  a  different  instantiation,  which  is  then  accessed  via  a  “next .callback”  operation  provided 
as  a  generic  actual  from  a  previous  (cascaded)  instantiation. 

Since  this  explanation  may  be  obscure,  an  example  usage  of  this  implementation  is  pro¬ 
vided  in  figure  7.  Note  that  this  usage  generates  only  one  procedure  reference  per  instantia¬ 
tion,  despite  the  fact  that  the  generic  interface  allows  as  many  as  three  procedure  references 
to  be  generated.  This  is  done  for  simplicity  to  illustrate  the  use  of  cascaded  generics  as  a 
means  of  achieving  an  open-ended  mechanism  for  attaining  procedure  references. 

One  advantage  of  this  approach  (beyond  it’s  pure  use  of  Ada)  is  that  application  pro¬ 
grammers  (i.e.,  toolkit  clients)  can  add  application-defined  subprogram  type  instances  to 
cascades  of  pre-defined  (i.e.,  by  the  toolkit  intrinsics  or  widget  programmers)  subprogram 
type  instances.  This  reduces  potential  configuration  management  problems  that  would  be 
introduced  if  all  subprogram  type  instances  needed  to  share  the  same  case  statement  dis¬ 
patcher. 

One  problem  with  thi6  implementation  concerns  the  visibility  of  the  top-level  (i.e.,  “last”) 
generic  instantiation  in  the  cascade.  For  systems  such  as  Xt,  which  execute  client  subpro¬ 
grams  based  upon  event  sequences  generated  from  the  server,  client  defined  subprogram 
references  must  be  visible  to  the  toolkit  intrinsics,  in  addition  to  widget  and  intrinsics  de¬ 
fined  subprogram  references.  As  a  result,  the  toolkit  must  either  be  (at  some  level)  a  generic 
abstraction  which  parameterizes  the  “call”  operation  for  each  procedure  type,  or  else  the 
application  programmer  must  complete  the  implementation  of  a  top-level  non-generic  call 
interface  whose  implementation  will  reference  the  top-level  generic  cascade. 

Turning  the  intrinsics  into  a  generic  abstraction  is  not  tenable  for  reasons  which  were 
discussed  in  the  previous  section.  Requiring  the  application  programmer  to  complete  the 
procedure  call  implementations  appears  to  introduce  a  considerable  degree  of  inconvenience, 
but  perhaps  this  is  outweighed  by  the  added  level  of  machine  independence.  The  UR-20 
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package  callback.aechanism  is 


CALLBACK.CALL.ERROR:  exception ; 
CALLBACK. IISTALL. ERROR :  exception ; 
CALLBACI.RAIGE.ERROR:  exception; 


HAZ. CALLBACKS :  constant:*  1024; 
VUH.CALLBACKS :  constant:*  3; 


subtype  callback.id.range  is  natural  range  0  . .  MAX.CALLBACES ; 

package  callback.ids  is 

type  callback.id.type  is  private; 
null. id:  constant  callback.id.type; 

function  to_callback_id_range(id:  callback.id.type) 
return  callback.id.range; 

private 

function  next.eallback.id  return  callback.id.range; 
type  callback.id.type  is  record 

the.callback.id:  callback.id.range:*  next.eallback.id; 
end  record; 

null.id:  constant  callback.id.type:* 

(the.callback.id  *>  callback.id.range' f irst) ; 
end  callback.ids; 


use  callback.ids; 


--  the  default  procedures  vill  never  actually  be  called 
procedure  default_next.call_back(id:  callback.id.type;  s:  string); 
procedure  default. callback (s :  string); 


generic 

with  procedure  cbl(s:  string)  is  default. callback; 

idl  :  in  callback.id.type:*  null.id; 

sith  procedure  cb2(s:  string)  is  default.callback; 

id2  :  in  callback.id.type:*  null.id; 

with  procedure  cb3(s:  string)  is  default.callback; 

id3  :  in  callback.id.type:*  null.id; 

vith  procedure  next_callback(id:  callback.id.type;  s:  string) 
is  default.next_call.back; 


package  callbacks  is 

procedure  callback  (id  :  callback.id.type;  s:  string); 
end  callbacks; 


end  callback .mechanism ; 
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Figure  6:  Procedure  Types  -  Generics  Generation 
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with  callback.Bechanisa;  use  callback.Bechanisa; 
with  text.io;  use  text.io; 
proeadura  test.callback.nechanism  is 
use  eallback.ids; 

proeadura  p(s:  string); 
proeadura  q(s:  string); 

pi:  callback. id. type;  --  pi  and  ql  now  hava  valid  callback  ids 
ql :  callback. id.type ; 

—  in  p.callbaeks,  cb2  and  cb3  ara  "default"  callbacks 
packaga  p.callbaeks  is  naw  callbaeks(cbl  •>  p,  idl  ■>  pi); 

~~  q.callbacks  usas  p.callbaeks  callback  routine  to  chain  instantiations 

—  proeadura  p  and  q  could  hava  both  baan  installed  in  a  single 
~~  instantiation,  but  we’re  demonstrating  instantiation  chaining, 
packaga  q.callbacks  is  naw  callbacks ( 

cbl  *>  q, 
idl  «>  ql, 

next.callbaek  ■>  p.callbaeks . callback) ; 
usa  q.callbacks;  —  Bake  the  last  instantiation  directly  visible 

—  procedures  p  and  q  do  different  things 
procedure  p(s:  string)  is 

begin 

put.linaC’P:"  ft  s); 
and  p; 

procedure  q(s:  string)  is 
begin 

put_line("Q:M  ft  s); 
and  q; 

begin 

callback (pi,  "hallo  world"); 
callback (ql,  "hallo  world"); 
and  test.callback.Bechanism; 


Figure  7:  Procedure  Types  -  Sample  Usage 
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toolkit  does  not  use  the  cascading  generics  implementation;  however,  the  procedure  invoca¬ 
tion  interface  actually  used  is  not  inconsistent  with  the  cascading  generics  implementation. 

Another  apparent  problem  concerns  performance.  A  considerable  amount  of  code  needs 
to  be  executed  just  to  locate  the  appropriate  procedure  to  execute.  This  problem  is  com¬ 
pounded  if  several  cascades  of  generics  are  needed.  Although  the  generic  abstraction  can 
be  implemented  to  accommodate  more  procedure  formals,  architectural  considerations  may 
require  several  cascades,  e.g.,  one  instantiation  for  intrinsics  defined  subprogram  instances, 
one  for  widget  defined  instances  (perhaps  one  for  each  widget  type),  and  finally  at  least  one 
for  the  application  itself 

3.3.4  System  Dependent  Programming 

Yet  another  alternative  implementation  scheme  for  introducing  subprogram  types  takes  ad¬ 
vantage  of  the  system-dependent  Ada  attribute  ‘ address ,  applied  to  subprogram  instances. 
Although  this  attribute  “refers  to  the  machine  code  associated  with  the  corresponding  body,” 
(Ada  LRM),  this  definition  leaves  open  considerable  compiler  implementation  leeway,  and 
so  any  solution  based  upon  this  feature  is  inherently  non-portable,  both  across  compilation 
systems  and  host  environments. 

Nevertheless,  thi6  form  of  system  dependent  programming  appears  to  be  more  justifi¬ 
able  than,  for  example,  the  unchecked  programming  used  in  the  task-based  simulation  noted 
above.  Also,  although  non-portable,  the  amount  of  system-dependent  code  required  to  im¬ 
plement  subprogram  types  with  the  'address  attribute  appears  to  be  rather  small,  assuming 
the  compilation  system  provides  adequate  documentation  on  procedure  call  conventions  (and 
does  indeed  implement  the  'address  attribute  in  a  reasonable  way). 

The  package  specification  for  a  sample  subprogram  type  is  provided  in  figure  8.  (This 
subprogram  type  will  be  referred  to  later  in  this  report  when  runtime  inheritance  is  de¬ 
scribed).  The  package  body  is  provided  in  appendix  B  for  the  VADS,  TeleSoft,  and  Tartan 
compilers.  1  The  procedure  control  block  structure  is  tailored  for  use  with  Alsys,  although 
the  same  data  structure  also  works  for  VADS  and  TeleSoft  (the  data  fields  are  not  used  in 
these  compilers). 

The  interpretation  of  this  implementation  is  very  similar  to  that  described  in  the  cas¬ 
caded  generics  implementation:  the  generic  instantiation  generates  a  unique  identifier  for 
the  subprogram  type  instance.  In  fact,  the  package  interface  is  nearly  identical,  and  for 
practical  purposes  the  implementations  are  interchangable  (which  is  convenient,  in  case  the 
system-dependent  approach  is  unworkable  for  a  given  compiler).  The  major  difference  is  that 
the  implementation  of  the  “call”  subprogram  dispatch  procedure  will  be  in  C  or  assembly 
language,  or  some  language  which  can  de-reference  subprogram  addresses  (in  effect,  execute 
a  “jump  subroutine”  or  “jsr”  instruction). 

‘The  Alsys  implementation  is  more  convoluted  due  to  difficulties  in  getting  documentation  on  the  Alsys 
procedure  call  conventions. 
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package  xt.procedure.types  is 

—  vendor-specific  procedure  control  block: 
type  procedure.control.block  is  record 
proc.address  :  system. address; 

—  subprogram  environment  context  data  fields  here... 
end  record; 


package  xt.vidget.elass.procs  is 

type  xt .widget. class. proc.rep  is  limited  private; 

type  xt.eidget_class.proe  is  access  xt.vidget_class_proc.rep; 

—  A  constant  used  for  runtime  inheritance  resolution: 

function  xt.inherit.vidget.class.proc  return  xt.sidget.class.proc; 

--  the  subprogram  dispatch  function: 

procedure  call(the_proc_id  :  xt .widget. class.proc; 

the.vidget. class  :  vidget.class) ; 


--  this  generic  is  instantiated  with  the  procedure  to  be  called 

—  proc.id  will  acquire  the  address  of  the  the.proc  as  well  as 

—  the  (activation  frame)  environment  needed  to  execute  the.proc 
g*n*ric 

proc.id  :  in  out  xt.vidget_elass.proc; 

with  procedure  the_proe(the_vidget_class  :  vidget.class); 
package  procedure.pointer  is 
end  procedure.pointer; 


private 

type  xt_vidget_class.proc.rep  is  new  procedure.control.block; 


end  xt.vidget.class.procs; 

—  other  procedure  type  definitions  follow... 


end  xt.procedure.types; 
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Figure  8:  Procedure  Types  -  System  Dependent 


3  DESIGN  APPROACH 


22 


It  should  not  be  concluded  that  this  mechanism  is  completely  without  restrictions.  In 
fact,  several  very  subtle  problems  can  be  encountered,  and  great  care  must  be  taken  in 
defining  procedure  types  for  use  with  this  implementation. 

One  major  area  of  concern  is  related  to  parameter  passing  conventions:  successful  use  of 
this  implementation  requires  an  adequately  documented  compilation  system.  For  example, 
an  unconstrained  array  can  be  implemented  as  an  array  with  a  dope  vector;  such  arrays  can 
quite  naturally  be  passed  to  subprograms  via  two  parameters,  not  one.  Thus,  in  general 
the  foreign  language  “call”  routine  will  have  to  be  tailored  for  each  subprogram  type  to 
accommodate  passing  different  numbers  and  types  of  arguments. 

Note:  The  UR20  implementation  actually  employs  a  single  dispatch  function  that  invokes 
ada  subprograms  via  their  address,  and  passes  only  a  single  argument  -  the  address  of  a  record 
structure  which  encapsulates  the  set  of  arguments  defined  for  various  procedure  types.  See 
appendix  B  for  the  details  of  this  optimization. 

A  second  area  of  concern  is  related  to  the  consequences  of  Ada  subprogram  and  type 
elaboration  issues.  Essentially,  safe  use  of  this  implementation  requires  the  programmer 
ensure  that  the  subprogram!  body  and  all  types  used  by  the  subprogram  be  fully  elaborated 
before  the  subprogram  reference  is  obtained  via  instantiation. 

Finally,  and  perhaps  most  importantly,  safe  use  of  the  system-dependent  implementation 
requires  thoughtful  application  of  usage  guidelines  which  ensure  that  the  subprogram  object 
will  exist  only  in  scopes  compatible  with  the  referenced  subprogram.  That  is,  care  must 
be  taken  to  ensure  that  the  environment  (e.g.,  stack  activation  frames)  appropriate  for  the 
referenced  subprogram  exists  at  the  time  the  subprogram  is  called.  This  could  have  been 
enforced  in  the  language  by  providing  the  call  operation  as  part  of  the  generic  subprogram 
type  abstraction,  rather  than  in  a  global  context;  however,  this  would  have  resulted  in 
visibility  problems  described  in  the  previous  section  on  cascading  generics.  A  simple  usage 
guideline  for  the  system-dependent  implementation  is  to  introduce  the  subprogram  object 
declaration  within  the  same  scope  which  contains  the  subprogram  declaration. 


3.4  Inheritance  and  Polymorphism  in  Ada/Xt 

The  notions  of  inheritance  and  polymorphism  are  closely  related  in  object  oriented  systems. 
Crudely,  polymorphism  describes  a  type  model  in  which  operations  (in  general,  properties  ) 
defined  on  a  single  type  sire  applicable  to  a  family  of  related  types.  Ada  generics  provide 
a  form  of  parametric  polymorphism,  i.e.,  a  set  of  operations  is  applicable  to  a  type  if  that 
type  is  parameterized  by  a  set  of  known  properties,  e.g.,  is  assignable,  has  equality  defined, 
has  an  ordering  relation  defined,  etc.  This  is  sufficient  only  if  the  types  in  a  system  can 
be  characterized  by  a  finite  number  of  known  properties.  This  is  not  the  case  in  an  object- 
oriented  class  hierarchy,  which  defines  (via  inheritance)  an  inclusion  polymorphism  type 
model. 

The  Ada/Xt  toolkit  simulates  polymorphism  and  inheritance  by  means  of  a  visible 
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pseudo-type  hierarchy  which  provides  a  logical  type  system  to  support  a  (apparent)  poly¬ 
morphic  external  programmatic  interface,  and  a  private  actual-type  hierarchy  to  support  the 
implementation  of  inheritance.  That  is,  the  pseudo-types  are  “public”,  i.e.,  visible  in  the 
API,  whereas  the  actual  types  are  “private”,  i.e.,  visible  only  to  widget  programmers.  This 
usage  of  the  terms  public  and  private  is  analogous  to  Ada  public  and  private  types,  but  is 
not  implemented  in  terms  of  Ada  private  types. 

3.4.1  Pseudo- Types  and  Compiled  Data  Structures 

The  Ada/Xt  type  hierarchy  is  actually  composed  of  four  parallel  hierarchies:  a  hierarchy 
of  widget  class  pseudo-types,  a  hierarchy  of  widget  instance  pseudo  types,  and  a  hierarchy 
of  actual  widget  class  and  instance  types.  The  programmatic  interfaces  to  the  toolkit  are 
implemented  in  terms  of  the  pseudo-types,  so  called  because  in  reality  these  types  are  merely 
placeholders  for  the  actual  types,  defined  by  widget  programmers. 

Figure  9  provides  a  pictorial  representation  of  the  Ada  toolkit  type  implementation. 
Widget  class  pseudo-types  are  arranged  in  an  Ada  subtype  hierarchy;  widget  instance  pseudo¬ 
types  are  arranged  in  a  (parallel)  derived  type  hierarchy.  Within  the  implementation  of  the 
intrinsics  and  widgets,  toolkit  code  performs  unchecked  conversions  from  Ada  objects  of  type 
pseudo-type  to  the  corresponding  actual  type  in  the  parallel  actual-type  hierarchy. 

This  set  of  parallel  type  hierarchies  provides  a  number  of  important  features  for  the 
Ada/Xt  implementation.  The  pseudo-type  hierarchy  allows  the  toolkit  to  be  extensible 
with  respect  to  widget  set6.  By  defining  the  intrinsics  operations  in  terms  of  pseudo-types 
rather  than  actual  widget  types  (i.e.,  their  Ada  record  representations),  one  set  of  intrinsics 
functions  can  manipulate  an  open-ended  number  of  actual  widget  types. 

A  further  refinement  of  the  pseudo-type  hierarchy  is  possible  due  to  the  Ada  derived  type 
feature.  Occasionally,  widget  programmers  may  wish  to  define  operations  on  widgets  which 
are  accessible  directly  to  the  application  programmer.  For  example,  text  edit  widgets  may 
provide  operations  to  retrieve  the  currently  selected  segment  of  text  within  the  editor  view. 
2  In  Ada/Xt,  the  widget  programmer  can  define  6uch  operations  on  a  widget.  Subclasses 
of  this  widget  will  “inherit”  operations  via  Ada  type  derivation  on  the  pseudo-types.  The 
operation  will  still  be  applicable  on  subclass  instances  because  the  code  “inherited”  will  be 
performing  an  unchecked  type  conversion  to  a  record  structure  which  is  layout-compatible 
with  the  subclass  instance’s  actual  type.  Thus,  the  pseudo/actual-type  hierarchy  in  effect 
augments  Ada  type  derivation  with  type  representation  changes. 

Note  that  the  use  of  unchecked  conversion  from  pseudo  types  to  record  type  definitions  in 
the  parallel  actual-type  hierarchy  requires  strict  widget  programmer  control  over  the  layout 

JNot*:  for  the  most  part,  application  programmers  make  application  operations  available  to  the  widgets 
to  be  executed  by  the  widget  or  toolkit  on  behalf  of  the  application.  This  kind  of  inversion  is  typical 
of  event-based  programming,  and  distinguishes  toolkit  programming  from  “traditional"  procedure-based 
programming  styles. 
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Peeudo-Type  Hierarchy  Actual-Type  Hierarchy 


Figure  9:  Ada/Xt  Widet  Type  Model 
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of  the  actual-type  record  definitions.  That  h,  for  an  operation  defined  on  object  class  1  (in 
figure  9  )  to  work  on  an  instance  of  object  class  3,  the  actual  representation  of  the  record  for 
instances  of  class  1  and  class  3  must  be  identical  for  the  common  prefix  fields,  i.e.,  for  the 
components  defined  in  the  record  definition  for  class  1.  Proper  enforcement  of  this  constraint 
only  can  be  ensured  through  use  of  Ada  record  representation  clauses. 

3.4.2  Packaging  Widget  Type  Definitions 

As  indicated,  a  widget  type  definition  consists  of  four  distinct  hierarchies,  arranged  as  a 
“public”  and  “private”  widget  definition  interface.  The  public  interface  is  defined  in  terms 
of  the  pseudo  types,  and  defines  operations  that  are  to  be  available  to  the  application  pro¬ 
grammer. 

The  private  interface  is  defined  in  terms  of  Ada  record  definitions  which  characterize  the 
object  state  for  widget  classes  and  instances.  In  order  to  ensure  that  widget  subclasses  share 
a  common  data  structure  prefix  with  their  ancestors  in  the  superclass-subclass  hierarchy,  the 
widget  programmer  must  explicitly  insert  the  record  type  definitions  for  the  type  hierarchy 
of  the  subclass’s  ancestors,  and  use  Ada  record  representation  clauses  to  ensure  the  relative 
ordering  of  these  fields  within  the  newly  defined  widget. 

Figure  10  illustrates  the  packaging  structure  for  defining  widgets  in  the  Ada/Xt  toolkit. 
This  mechanism  is  quite  similar  to  the  method  used  in  the  C  implementation,  with  the 
major  differences  being  the  use  of  representation  clauses,  and  the  use  of  Ada  derived  types 
to  automate  some  of  the  inheritance  process.  Note  that  the  Ada  “with”  hierarchy  parallels 
the  superclass-subclass  taxonomy  defined  by  the  logical  widget  class  structure.  * 

The  Ada  packaging  scheme  described  in  figure  10  has  some  interesting  consequences 
conerning  order  of  elaboration.  In  short,  the  widget  type  taxonomy  must  be  elaborated  in 
superclass  to  subclass  order;  this  can  be  enforced  through  use  of  the  pre-defined  Ada  pragma, 
elaborate.  Appendix  C  of  this  report  illustrates  the  current  UR-20  Ada/Xt  implementation’s 
widget  packaging  scheme  by  providing  the  full  package  specification  and  implementation  for 
the  (opaque)  widget  type,  simple^widget. 

3.4.3  Subprogram  and  Resource  Inheritance 

The  actual  type  hierarchy  provides  the  data  structures  to  support  inheritance,  but  not  the  full 
implementation.  Inheritance  of  subprograms  and  resources  (i.e.,  widget  data  fields  accessible 
to  the  application  programmer  by  named  reference)  is  performed  once  per  widget  class,  at 
run-time,  in  the  Ada/Xt  implementation.  Although  this  is  an  implementation  detail,  it  has 
some  impact  on  the  way  widget  programmers  specify  widget  data  structures. 

Each  time  a  widget  is  created  (using  zt.create.widget)  the  intrinsics  check  to  see  that  the 

*An  additional  “with"  dependency  exists  between  the  body  of  the  public  implementation  and  the  private 
specification  for  implementation  purposes. 
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Public  (Pseudo)  Types  Private  (Actual)  Types 


Legend 


B  "withs"  A 


Figure  10:  Widget  Types  -  Ada/Xt  Packaging  Convention 
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widget  class  of  the  newly  created  widget  has  been  initialized.  If  it  has  not  been  initialized, 
the  intrinsics  invokes  a  class  initialization  procedure  which  puses,  in  superclass-to-subdass 
order,  the  uninitialized  widget  class  actual  data  structure  to  the  class  initialization  procedure 
defined  for  all  widget  classes  (defined  as  the  class. part. initialize  operation  in  core.class). 

Each  cl ass.part .initialize  operation  is  responsible  for  performing  subprogram  inheritance 
(besides  other  class  initialization  actions)  of  subprograms  (“methods”)  defined  for  the  su¬ 
perclass.  The  dass.part initialize  code  examines  the  procedure  type  fields  of  the  subclass 
structure  passed  to  it.  If  any  of  these  fields  have  special  values  (called  “inherit”  values), 
the  dass.part  .initialize  operation  will  overwrite  these  fields  with  the  subprogram  reference 
being  inherited  from  the  superdass.  Thus,  it  is  the  responsibility  of  the  widget  programmer 
to  request  inheritance  of  superdass  methods  by  use  of  specially  defined  constants;  it  is  also 
the  responsibility  of  the  widget  programmer  to  implement  the  dass.part  -initialize  operation 
to  correctly  implement  inheritance  of  inheritable  methods  defined  by  widget  classes. 

Inheritance  of  resources  is  managed  by  the  intrinsics  (i.e.,  it  is  more  fully  automated).  The 
implementation  of  .ssource  inheritance  is  similar  to  method  inheritance:  it  is  done  during 
a  one-time  initialization  of  a  widget  dass  via  a  superdass-to-subclass  chaining.  However, 
instead  of  calling  widget-specific  initialization  code,  the  intrinsics  performs  a  resource  list 
merging  and  compilation  process.  The  result  is  that  each  widget  dass  instance  has  a  list  with 
its  resources,  and  the  resources  of  all  of  its  superdasses.  The  list  is  ordered  in  a  subclass-to 
superclass  fashion,  so  that  subdasses  may  “override”  inherited  resources.  Thus,  it  is  the 
responsibility  of  the  widget  programmer  to  spedfy  a  list  of  resources  which  the  intrinsics 
will  then  “compile”  and  merge  with  other  lists  at  dass  initialization  time.  This  merging 
i6  a  run-time  optimization  which  bypasses  the  need  for  inheritance  searches  for  referenced 
resources. 

4  The  Ada/Xt  Design 

The  design  approach  described  in  the  previous  section  allows  the  Ada  specification  of  data 
types  and  functional  interface  to  follow  the  C  specification  quite  closely.  The  following 
sections  describing  the  Ada  specifications  for  the  Xt  Intrinsics  follow  the  C  specifications 
described  in  [3].  Each  section  corresponds  to  a  similar  chapter  in  [3],  and  the  specifications 
should  be  read  in  conjunction  with  [3].  Where  the  semantics  of  the  subprograms  differ  from 
the  C  version,  the  differences  are  noted,  otherwise  the  semantics  are  as  described  in  [3]. 

Obviously,  there  are  differences  between  the  Ada  specification  and  the  C  specification. 
Most  of  the  differences  can  be  categorized  into  the  following  categories: 

•  C  functions  with  side  effects 

•  pointers  versus  out  parameters 

•  length  for  list  parameters 
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•  argument  list  assignment 

•  representation  of  resource  lists 

•  procedure  types 

Any  C  function  returning  a  value  and  having  side  effects  on  parameters  has  been  changed 
to  an  Ada  procedure  with  one  additional  argument  whose  type  is  the  return  value  type.  Since 
C  does  not  allow  out  parameters  to  functions,  pointers  are  used.  Wherever  possible  out 
parameters  of  the  base  type  are  used  instead  of  pointers  to  the  base  type.  Ada  provides 
the  length  attribute  for  arrays  which  can  be  used  instead  of  supplying  a  count  or  length  for 
arrays  passed  as  parameters.  The  C  count  parameters  are  removed  wherever  possible.  The 
next  two  differences  are  closely  related  to  resource  management  and  are  discussed  at  length 
in  the  resource  management  section. 

Procedure  type  specification  in  Ada  is  described  in  the  design  approach,  and  all  procedure 
type  specifications  are  provided  as  pseudo  type  declarations  at  the  end  of  each  section.  These 
pseudo  type  declarations  represent  instantiations  of  package  templates.  The  following  is  the 
template  for  procedure  type  packages: 

package  <procedure  type  name>_procs  is 

type  <procedure  type  name>_proe_rep  is  limited  private; 

type  <procedure  type  name>_proc  is  access  xt_callback.proc.rep; 

function  xt_inherit_<procedure  type  name> 

return  <proeedure.type_name> ; 

procedure  call  (the.proc.id  :  <proeedure  type  name>; 

<the  procedure  arguments>); 

generic 

proc.id  :  in  out  <procedure  type  name>_proc; 
with  procedure  the.proc  (<the  procedure  arguments>); 
package  procedure.pointer  is 
end  procedure.pointer; 


private 

--  proceduxe.control.block  is  inplementation  defined 
type  <procedure  type  naae>_pxoc_rep  is  new  procedure.control.block; 
end  <procedure  type  name>.procs; 

Procedure  type  package  definitions  appear  in  the  specification  as: 

pseudo.type  <procedure  type  naae>  is 

new  proc_type(<the  procedure  arguments>); 

For  example,  the  procedure  type  zt. widget. class. proc ,  which  is  a  procedure  with  a  single 
widget  .class  argument,  is  defined  as: 

pseudo.type  xt_widget.class.proc  is 

new  proc_type(wc:  widget. class) ; 
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A  number  of  fundamental  data  types  are  implementation  dependent,  and  are  noted  in  the 
specifications.  Additional  types  are  defined  as  private,  but  left  unspecified.  These  represent 
opaque  data  types  such  as  translation  tables  and  resource  databases  and  are  not  defined 
in  these  specifications.  The  specifications  use  data  types  defined  in  the  Ada  Xlib  bindings. 
These  are  contained  in  the  z-windowa  package  specification  and  are  not  included  in  this 
document. 

Packaging  Considerations 

In  the  following  sections,  the  types  and  subprogram  interfaces  which  comprise  the  system- 
independent  Ada/X  Toolkit  specification  are  defined  as  a  series  of  packages.  These  packages 
encapsulate  groups  of  related  types  and  operations,  and  in  many  cases  correspond  exactly 
with  groups  of  related  operations  as  defined  in  [3],  However,  the  packaging  structure  de¬ 
fined  in  the  following  sections  should  be  viewed  as  a  guideline  for  implementing  conformant 
Ada/Xt  implementations;  alternative  packaging  models  may  be  desirable  or  even  necessary 
under  some  circumstances. 

For  example,  the  UR20-UI  Ada/Xt  implementation  defines  the  pre-defined  widget  and 
widget  classes  in  separately  compiled  Ada  packages.  This  packaging  model  makes  the  core 
widget  definitions  dependent  upon  the  intrinsics  package,  which  defines  the  type  marks  for 
widget-class  and  widget.  This  packaging  scheme  relies  upon  the  implicit  assumption  that 
there  exists  a  mechanism  to  perform  type  conversions  between  objects  of  type  e.g.,  widget  - 
implemented  in  UR20’6  implementation  as  a  system. address  -  to  objects  of  type  corejwidget. 
Should  this  assumption  prove  invalid  on  a  given  architecture  (e.g.,  an  architecture  with  two 
addressing  modes,  such  as  32  and  48  bit  addressing  modes,  might  implement  system. address 
as  a  variant  record),  alternative  implementations  may  impose  alternative  packaging  models. 
For  example,  in  the  above  multi-address  type  architecture,  the  pre-defined  core  type  could 
be  defined  in  a  subpackage  of  the  intrinsic6  package;  then  type  widget  could  be  defined  as  an 
access  to  type  core.  This  would  bypass  the  need  to  convert  system  address  types  to  widget 
types  4. 

The  following  specifications  try  to  strike  a  balance  between  sufficient  conciseness  and 
overspecification.  Specific  type  representations  or  packaging  decisions  should  be  considered 
as  very  strong  recommendations.  For  example,  the  decision  to  represent  a  list  type  as  an 
unconstrained  array  of  some  base  type  should  be  considered  part  of  the  system-independent 
specification;  also,  the  decision  to  include  a  type  within  a  package  is  a  similar  “strong  rec¬ 
ommendation.”  In  many  cases,  however,  type  definitions  are  not  given  a  package  context;  in 
these  cases,  implementations  should  consider  themselves  free  to  determine  their  own  pack¬ 
aging. 

Figure  11  provides  a  top-level  overview  of  the  packaging  structure  for  the  UR20-UI 

4 Although  it  would  still  be  necessary  to  perform  type  conversions  between  dittinet  access  types. 
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Ada/Xt  implementation.  The  figure  does=not  include  all  of  the  pre-defined  widget  type 
dependencies;  those  that  are  included  are  representative  of  the  packaging  model. 

Note  that  the  following  specifications  assume  a  foundational  set  of  X  types,  as  for  example 
defined  in  the  SAIC  STARS  Foundations  Ada/Xlib  bindings.  In  the  following  specifications, 
such  types  are  prefixed  by  “x.windows.fype,”  even  though  the  Ada/Xlib  bindings  may  require 
deeper  qualification  to  subpackages.  Types  that  are  not  preceded  by  the  x.window6  package 
name  can  be  assumed  to  be  either  intrinsic  types  to  Ada,  or  defined  by  Ada/Xt. 

Finally,  note  that  some  types  are  referenced  before  they  are  defined.  This  is  necessary  in 
order  to  associate  type  declarations  with  appropriate  operations. 
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4.1 


Widgets 


The  basic  abstraction  in  the  toolkit  is  the  widget  and  its  associated  widget  class.  The  three 
basic  widget  types 


1.  Core 


2.  Composite 

3.  Constraint 

are  described  here.  The  structures  representing  these  three  widget  types  map  directly  to 
the  C  data  structures.  See  1.3  of  [3]  for  a  complete  discussion  of  widgets.  All  widgets  are 
derived  types  of  an  implementation  defined  type  widget  or  subclasses  of  widget ,  and  widget 
classes  are  subtypes  of  an  implementation  defined  type  widget.claas  or  subclasses  of  type 
widget-claaa.  widget  and  widget-cloas  are  usually  some  form  of  physical  address  to  the  data 
structures  described  in  this  section.  The  intrinsics  provide  conversion  routines  for  all  the 
widget  and  widget  class  types  known  to  the  intrinsics.  The  default  values  for  the  widget 
types  described  here  are  the  same  as  specified  in  1.3  of  [3]. 


4.1.1  Core  Widgets 


The  following  types  are  assumed  to  be  visible  to  the  core-private  package  specification,  and 
are  not  defined  elsewhere  in  this  report: 


type  widgat  ia  implementation.def inad; 

type  widgat- class  is  implementation. def inad; 

type  widget.list  is  array  (natural  range  <>)  of  widget; 

type  widget. list.ptr  is  access  widget.list; 


type  cardinal  is  range  0  . .  implementation-defined; 
subtype  position  is  cardinal; 
subtype  dimension  is  cardinal; 


subtype  xt.offset  is  cardinal; 

type  xt.offset.list  is  array  (natural  range  <>)  of  xt.offset; 
type  xt.offset.list.ptr  is  access  xt.offset.list; 

type  xt.string  is  access  string; 

type  xt.boolean  is  implementation.def inad; 
type  xt.version.type  is  implementation.def inad; 


The  following  package  defines  the  pre-defined  core  widget  class  and  instance  types: 
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package  core.private  ia 

— 1)  define  widget .part  (core  ie  special  case  —  no  nested  records) 

core.part.size  :  constant  cardinal  :*  implementation.def ined; 
type  core.part  is  record 
self  :  widget; 
widgetclass  :  widget.class; 
parent  :  widget ; 

the.xrm.name :  z. windows .  xm.name ; 

being.destroyed  :  xt .boolean; 

destroy. callbacks :  xt.callback_list.ptr ; 

constraints  :  x. windows . caddr.t ; 

x  :  position; 

y  :  position; 

width  :  dimension; 

height:  dimension; 

border .width  :  dimension; 

managed  :  xt .boolean; 

sensitive:  xt .boolean; 

ancestor. sensitive  :  xt .boolean; 

event .table  :  xt. event .table; 

tm  :  xt.TH.Ree; 

accelerators  :  xt .translations ; 
border. pixel  :  x_ windows. pixel; 
border.pixmap  :  x.windows.pixmap; 
popup .list  :  widget .list. ptr; 
name  :  xt .string; 
my.screen  :  x. windows. screen; 
my.colormap:  x_ windows. color. map; 
my. window  :  x.windows . window ; 
depth  :  cardinal; 

backgronnd.pixel  :  x.windows. pixel; 
backgronnd.pixmap  :  x.windows.pixmap; 
visible  :  xt .boolean; 
mapped.when.managed  :  xt .boolean; 
end  record; 

type  core.part .pointer  is  access  core.part; 
type  core.widget.pointer  is  access  core.part; 

—  2)  define  class  part 

core.class.part.size  :  constant  cardinal  :*  implementation.def ined; 
type  core.class.part  is  record 
superclass  :  widget.class; 
class.name  :  xt.string; 
widget.size:  cardinal; 
class.initialize  :  xt.proc; 

class.part. initialize  :  xt.widget_class.prec; 
class.inited  :  xt.boolean; 
initialize  :  xt.init.proc; 
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initialize.hook  :  zt.args.proc; 
realize  :  xt.realize.proc; 
actions  :  zt_action.list.ptr; 
rosoureos:  zt.rasourcs.list.ptr; 
ths.zm.elass :  z. windows .xrm. class; 
compress.motion  :  zt.boolsan; 
compress .exposure  :  zt .boolean; 
compress.interleave  :  zt.boolsan; 

▼isibls.intsrsst  :  zt.boolsan; 
destroy  :  zt. widget _proc; 
resize  :  zt.widget.proc; 
expose  :  zt.expose.proc; 
set. values  :  xt.set.values.func; 
set .values. hook  :  zt.args.fune; 
set.values.almost  :  xt.almost.proc; 
get. values .hook  :  zt.args.proc; 
accept. focus  t  zt.aecept.foeus.proe; 
version  :  zt.version.type; 
callback.private  :  zt.offset_list.ptr; 

tn. table  :  zt. string; 

query .geometry  :  zt. geometry .handler; 
display.accelerator  :  zt.string.proc; 
extension  :  z.windows . caddr.t ; 
end  record; 

—  types  for  conversion  operations: 

type  core.class.part.pointer  is  access  core.class.part ; 
type  core.class.pointer  is  access  core.class.part; 

—  allocate  the  class  constant 

function  to.widget.class  is  new  unchecked. convers ion ( 
source  ■>  core.class.pointer. 
target  *>  widget. class) ; 

the.core.class  :  constant  widget. class  :• 

to. widget.class  (new  core.class.part) ; 

end  core.private; 

4.1.2  Composite  Widgets 

—  superclass  context 

with  core.private;  use  core.private; 
package  composite.private  is 

composite.part_rec.size  :  constant  cardinal  :■  implementation.def ined; 
type  compos ite.part.rec  is  record 
children  :  widget .list.ptr; 
num. slots  :  cardinal; 
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insert .position  :  xt.order.proc; 

•nd  record ; 

compoaite_wi.dget_si.ze  :  constant  cardinal  :■ 
core_part_size  +  composite_part_rec_size; 
type  compos it e_ widget _rec  ia  record 
eore.part  :  core .private. eore.part; 
composite.part  :  composite.part.rec; 

•nd  record; 

for  composite.widget.rec  nsa  record  at  mod  implementation.def ined; 
eore.part 
at  0 

range  0  ..  core.part.aize  -  1; 
composite.part 
at  0 

range  core.part.aize  ..  core.part.aize  ♦  compoaite_part.rec.aize  -  1; 
end  record; 

type  compoaite.part .pointer  ia  aeeeaa  composite.part.rec; 
type  composite.widget.pointer  ia  acceaa  composite.widget.rec; 

composite.elass_part_rec.size  :  constant  cardinal  :*  implementation.def ined; 
type  composite.claaa.part.rec  ia  record 
geometry .handler  :  zt. geometry .handler; 
change .managed  :  xt _ widget _proc; 
inaert.child  :  xt .widget .proc; 
delete. child  :  xt. widget .proc; 
extension  :  x.windows . caddr.t ; 

•nd  record; 

compoaite.claas_part.size  :  constant  cardinal  :» 

core_class.part.size  *  composite. class_part.rec.size; 
type  composite.clasa.part  ia  record 

core.class.part  :  core.private. core. class .part; 
composite.clasa.part  :  composite.class.part.rec; 
end  record; 

for  composite.clasa.part  use  record  at  mod  implementation.def ined; 
core.class.part 
at  0 

range  0  ..  core.ciass_part.size  -  1; 
composite. class .part 
at  0 

range  core.class.part.size  ..  composite.class_part.size  -  i; 
end  record; 

type  composite.class .part .pointer  is  access  composite.class.part.rec; 
type  composite.class.pointer  is  access  composite.class.part; 


—  allocate  the  class  constant 
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function  to.vidget. class  is  nsv  une£eeked_conversion( 
sourcs  *>  composite.class.pointer , 
target  «>  vidget.class) ; 

the. composite. class  :  constant  vidget.class  :  ■ 
to.vidget.class  (nsv  composite.class.part) ; 

and  composite.private; 


4.1.3  Constraint  Widgets 

—  superclass  context 

with  composite.private;  use  compos its. private; 
with  core.private;  use  core.private; 

package  conjtraint.private  is 

constraint .part.ree. size  :  constant  cardinal  :■  0; 
type  constraint.part.rec  is  record 
null; 

end  record; 

constraint. vidget.size  :  constant  cardinal  :■ 

conposite.vidget.size  ♦  constraint _part.rec.size; 
type  constraint.vidget.rec  is  record 
core.part  :  core.private. core .part; 

composite.part  :  composite_private.coaposite_part.rec; 
constraint .part  :  constraint .part _rec; 
end  record; 

for  constraint.vidget.rec  use  record  at  nod  iapleaentation.def ined; 
core.part 
at  0 

range  0  ..  core .part .size  -  1; 
composite.part 
at  0 

range  core.part.size  ..  conposite.vidget.size  -  1; 
constraint .part 
at  0 

range  coaposite.vidget.size  ..  constraint.vidget.size  -  1; 
end  record; 

type  constraint .part .pointer  is  access  constraint.part.rec; 
type  constraint .vidget .pointer  is  access  constraint.vidget.rec; 

constraint.class_part_rec.size  :  constant  cardinal  :■  laplementation.def ined; 
type  constraint.class.part.rec  is  record 
resources  :  xt.resource_list.ptr; 
constraint.size  :  cardinal; 
initialize  :  xt.init.proc; 
destroy  :  xt.vidget.proc; 
set.values  :  xt.set_values.func; 
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extension 
end  record; 


x.windows . caddr.t ; 


constraint. class .part .size  :  constant  cardinal  : ■ 

composite. class.part.size  ♦  constraint. class.part.rec. size; 
type  constraint .class. part  is  record 

core.class.part  :  core .private. core.class.part; 

composite. class.part  :  composite_private.composite_class_part.rec; 
constraint .class .part  :  constraint .class.part.rec; 
end  record; 


lor  constraint .class. part  use  record  at  mod  implementation.defined; 
core.class.part 
at  0 

range  0  ..  core_class.part.size  -  1; 
composite. class .part 
at  0 

range  core.class.part. size  ..  composite_class.part.size  -  1; 
constraint. class.part 
at  0 

range  composite.class.part.size  ..  constraint.class.part.size  -  1; 
end  record; 

type  constraint.class.part .pointer  is  access  constraint. class.part.rec; 
type  constraint. class.pointer  is  access  constraint.class.part; 


—  allocate  the  class  constant 


function  to.widget. class  is  nev  unehecked.conversionC 
source  ■>  constraint. class.pointer, 
target  ->  widget. class) ; 


the.constraint.class  :  constant  widget. class  : ■ 
to.widget.class  (new  constraint.class.part) ; 


end  constraint .private; 


4.1.4  Widget  Class  and  Superclass  Look  Up 

function  xt.class  (w  :  widget)  return  widget.class; 
function  xt.superclass  (w  ;  widget)  return  widget.class; 
function  xt.is. subclass  (w  :  widget; 

wc  :  widget.class)  return  boolean; 
procedure  xt.check.subclass  (w  :  widft; 

wc  :  widget.class; 

message  :  string); 
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4.2 


Widget  Instantiation 


This  section  describes  widget  instantiation.  Refer  to  chapter  2  of  [3]  for  a  complete  descrip¬ 
tion  of  widget  instantiation.  The  following  is  the  Ada  programmatic  interface  to  functions 
and  data  structures  required  for  widget  instantiation. 


4.2.1  Toolkit  Initialization 

The  following  types  are  assumed  to  be  visible  to  xt initializers,  and  may  be  declared  within 
this  package: 

type  application. context  is  private; 

The  package  specification  zt-initializera  specifies  subprograms  and  data  structures  used 
in  toolkit  initialization. 

package  xt.initializers  is 

procedure  xt. toolkit. initialize; 

function  zt.create.application.context  return  application.context; 


procedure  xt.destroy.application.context 

(context  :  in  out  application.context); 

f unct ion  xt .widget  _t o _ appli cat i on. context 

(«  :  widget)  return  application.context; 

procedure  xt .display. initialize  (app.context  :  application.context; 

the.display  :  x.windovs. display; 

appli cat ion.name  :  string; 
application.class  :  string; 
options  :  xrm.option_desc_rec.list; 
azgc  :  in  out  cardinal; 

argv  :  in  out  string); 


procedure  xt.open.display  (app.context 

display.string 

appli cat ion.name 

application.class 

options 

argc 

argv 

return.di splay 


application.context ; 

string; 

string; 

string; 

xrm.option_desc_rec.list ; 

in  out  cardinal; 

in  out  string; 

out  x_ windows . display) ; 


procedure  xt.close.display  (the. display  t  in  out  x.windows .display) ; 


end  xt.initializers; 
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4.2.2  Loading  the  Resource  Database 

function  xt.databasa  (the.display  :  x.windows. display)  return 
x.windows . xrm. database ; 


4.2.3  Parsing  the  Command  Line 

Although  Ada  compilers  differ  in  handling  the  Unix  notion  of  arge  and  argv ,  the  Ada  Toolkit 
recognizes  the  standard  X  command  line  options.  The  type  definitions  for  command  line 
option  description  records  are: 

type  xrm.option.kind  is  (xrm.option.no.arg, 

xm.  option,  is.arg, 
xrm.option.sticky.arg, 
xra.option.set.arg, 
xra.option_res.arg, 
xra.option.skip.arg , 
xra.option.skip.line) ; 

type  xra.option.desc.rec  is  record 
option  :  xt. string; 

resource.naae  :  xt .string; 

arg.kind  :  xza.option.kind; 

▼alue  :  x.windows . caddr.t ; 

end  record; 

type  xra_option.desc.list  is 

array  (latural  range  <>)  of  xra.option.desc.rec; 

4.2.4  Creating  Widgets 

Widget  creation  in  Ada  differs  only  in  its  treatment  of  argument  lists.  Argument  lists  in  C 
are  essentially  lists  of  untyped  data;  a  problem  for  strongly  typed  languages  like  Ada.  Since 
argument  lists  are  closely  related  to  resource  management,  a  discussion  of  the  handling  of 

these  lists  in  Ada  is  deferred  to  the  section  on  resource  management. 

The  following  types  are  assumed  to  be  visible  to  package  xt  instance  jmanagement,  and 
can  be  defined  within  this  package: 

subtypa  xt.arg.val  iax.xindows. caddr.t; 
typa  xt.arg  is  record 

nano  :  xt. string; 

▼aluo  :  xt.arg.val; 
and  racord; 

typa  arg.list  ia  array  (natural  ranga  <>)  of  xt.arg; 
typa  arg.liit.ptr  ia  accaaa  arg.list; 

The  following  package  declaration  provides  basic  instance  manipulation  primitives: 


package  xt.instanca.aianagona&t  is 
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function  xt. create. widget  (nan*  atring; 

of .class  :  widgat. class; 

parent  :  widget; 

args  :  arg.list)  return  widget; 

function  zt.app.create.shell  (application.name  :  string; 

application.class  :  string; 
wc  :  widget.class; 

the .display  :  x.windows. display; 

args  :  arg.list) 

return  widget; 


procedure  xt. add. callback  (w 

callback.nane 

callback 

client.data 


:  widget; 

:  string; 

:  xt.callback.proc; 

:  x_ windows. eaddr.t); 


procedure  xt. create. window  (w 

win.class 
the. visual 
value.aask 
attributes 


widget; 

x.windows .window.elass; 
x.windows . visual ; 
xt .value.aask ; 

x.windows .x.set.window.attributes) ; 


procedure  xt.realize.widget  (w  :  widget); 


procedure  xt.unreali2e.widget  (w  :  widget); 
procedure  xt.destroy .widget  (w  :  widget); 
function  xt .is .realized  (w  ;  widget)  return  boolean; 


function  xt.display  (w  :  widget)  return  x.windows .display; 
function  xt.parent  (w  :  widget)  return  widget; 
function  xt.screen  (w  :  widget)  return  x.windows. screen; 
function  xt .window  (w  s  widget)  return  x.windows. window; 


end  xt.instance.aanagement; 


4.3  Composite  Widget  Management 

specification  xt.composite.management  specifies  the  subprogram  units  providing 
managing  children  of  composite  widgets.  These  subprograms  are  described  in 

chapter  3  of  [3]. 

package  xt.composite.management  is 

function  xt.is.conposite  (w  :  widget)  return  boolean; 
procedure  xt.manage. children  (wlist  :  widget.list) ; 


The  package 
functions  for 


l 
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procadura  xt.aanaga.child  (child  :  widget); 

procedure  xt.unmanaga.childran  (wliit  :  widget. lilt) ; 

procedure  xt.unmanaga. child  (wliit  :  widget.liit) ; 

function  xt.ii.aanagad  (w  :  widget)  return  boolean; 

function  xt.craata.nanagad.widgat  (nine  :  itring; 

of.deii  :  widget. clan; 

parent  :  widget ; 

argi  :  arg.liit)  return  widget; 

procedure  xt.iat.nappad.whan.nanagad  (w  :  in  widget; 

■ap.whan.aangad  :  boolean  :«  true); 


end  xt.compoiite.nanagement ; 


4.S.1  Procedure  Typei  in  Compoiite  Widgeti 

The  following  package  specification  describes  the  procedure  type  for  the  insert-child  and 
delete.child  procedures  used  for  adding/deleting  children  of  a  composite  widget. 

pseudo.type  zt.widget.proc  is 

new  proc. type (the. widget  :  in  out  widget); 

The  procedure  type  for  specifying  the  insertion  order  of  children,  the  insert-position  field 
of  a  composite  widget,  is: 

pseudo.type  zt.order.proc  is 

new  proc.type(the_widget  :  in  out  widget); 


4.4  Shell  Widgets 

The  following  data  structures  specify  the  various  shell  widgets  described  in  chapter  4  of  [3]. 
The  shell  widgets  are: 

e  Shell 

e  Override  Shell 
e  WM  Shell 
e  Vendor  Shell 
e  Transient  Shell 
e  Top  Level  Shell 
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•  Application  Shell 
—  superclass  context : 

with  composite.private;  use  compos ite.private; 
with  core.private;  new  core.private; 

package  shell.private  is 

—  Define  various  shall  parts  and  widgat  record  extensions 

—  shell.widget 

shell.part_rec.size  :  constant  cardinal  :■  implementation.def ined; 
type  shell.part.rec  is  record 
geometry  :  xt .string; 
create.child_popup.proc  :  xt.proc; 
grab. kind  t  xt. grab .kind; 
spring.loaded  :  xt .boolean; 
popped.up  :  xt .boolean; 
allow.shell.resize  :  xt .boolean; 
client.specif ied  :  xt.boolean; 
save.under  :  xt.boolean; 
override.redirect  :  xt.boolean; 
popup. callback  :  xt .callback. liit.ptr; 
popdovn. callback  :  xt.callback.list.ptr; 
end  record; 

shell.widget.size  :  constant  cardinal  :■ 

composite.widget.size  *  shell.part.rec. size; 
type  shell.widget.ree  is  record 

core.part  :  core.private. core .part; 

composite.part  :  composite_private.eoaposite_part.rec; 
shell.part  :  shell.part.rec; 
end  record; 

for  shell.widget.ree  use  record  at  mod  implementation.def ined; 
core.part 
at  0 

range  0  ..  core .part .size  -  1; 

composite.part 

at  0 

range  core.part.size  . .  composite.widget.size  -  i; 
shell.part 
at  0 

range  composite.widget.size  . .  shell.widget.size  -  1; 
end  record; 

type  shell.part .pointer  is  access  shell.part.rec; 
type  shell.widget.pointer  is  access  shell.widget.ree; 

--  override.shell.widgat 

override.shell_part_rec.size  :  constant  cardinal  :■  implementation.def ined; 
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type  override.shell.part.rec  i>  record 
null; 

end  record; 

o**rrid*_sh*ll_widgwt_siz*  :  constant  cardinal  :■ 

•hell.widget .size  ♦  override.shell.part.rec.size; 
typ*  override.shell.vidget.rec  is  r*cord 
core.part  :  cora.privat* . core.part ; 
conposite.part  s  conposite_private.conposite_part.rec; 
shell.part  :  sh*ll_part_r*c; 
override.shell.part  :  override.shell.part.rec; 
end  record; 

fox  override.shell.vidget.rec  use  record  at  nod  inplementation.def ined; 
core.part 
at  0 

range  0  ..  core.part.size  -  1; 

conposite.part 

at  0 

range  core.part.size  ..  conposite.eidget.size  -  1; 
shell.part 
at  0 

rang*  composite.widget.siz*  ..  ahell.vidget.siz*  -  1; 
override.shell.part 
at  0 

rang*  shell.vidget.siz*  ..  override.shell.widget.siz*  -  1; 
end  record; 

typ*  ov*rrid*_sh*ll.part .pointer  is  access  override.shell.part.rec; 
typ*  override. shell.vidget.pointer  is  access  override.shell.vidget.rec; 

—  ns. shell. widget 

va.sh*ll_part_r*c.siz*  :  constant  cardinal  :■  inplementation.def ined; 
typ*  vm_sh*ll_part_r*c  is  record 
title  :  xt. string; 
vm_tim*out  :  x .windows. time; 
wait.for.vm  :  xt .boolean; 
transient  :  xt.boolean; 
size.hints  :  x.windows . caddx.t ; 

vm. hints  :  x.windows . caddr.t ; 
end  record; 

vn.shell_widget.siz*  :  constant  cardinal  :■ 

override. shell.vidget.siz*  *  wm.shell.part.rec.size; 
typ*  vm.shell. widget _r*c  is  record 
core.part  :  core.privat*. core.part; 

conposite.part  :  conposite_private.conposite_part.rec; 
shell.part  :  shell.part.rec; 
override.shell.part  :  ov*rrid*_sh*ll.part_r*c; 

vn. sholl.part  :  vn.shell.part.rec; 
end  record; 
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for  WB.tholl_vidgot.roc  mo  rocord  at  nod  implementation.def ined; 
coro.port 
at  0 

range  0  ..  coro.part.iizo  -  1; 

composito.part 

at  0 

range  core.part.aize  ..  compotito.vidgot.iize  -  1; 
tholl.part 
at  0 

range  coBpotite.vidget.tize  ..  ahell.vidget.tize  -  1; 
override _ tholl.part 
at  0 

range  ahell.vidget.tize  ..  override_thell.vidget.iize  -  1; 
wm_ tholl.part 
at  0 

range  override.ahell.vidget.tize  ..  VB_ihell.vidget.aise  -  1; 
end  record; 

type  vn_ehell_part .pointer  it  aeceti  VB.thell_part.rec; 
type  WB_ehell_vidget .pointer  it  aceett  vm_thell_vidget_rec; 

--  vendor. thell.vidget 


vendor_thell.part_rec.tize  :  conetant  cardinal  :»  implementation.def ined; 
type  vendor.thell.part.rec  it  record 

vendor.tpecif ic  :  implementation.def ined; 
end  record; 


vendor_thell.vidget.tize  :  conetant  cardinal  :■ 

vb_ ahell.vidget.tize  ♦  vendor.thell_part_rec.eize; 
type  vendor_ahell.widget.rec  it  record 
core.part  :  core_private.core.part; 

compoaite.part  :  coBpoeite.private.conpoeite.part.ree; 
tholl.part  :  tholl.part _rec; 

override.thell.part  :  override.thell.part.rec; 
VB.ihell.part  :  va_ tholl.part _rec; 
vendor .tholl.part  :  vendor.thell.part.rec; 
end  record; 


for  vendor.ehell.vidget.rec  me  record  at  Bod  iBpleBetation.defined; 
core.part 
at  0 

range  0  ..  coro.part.iizo  -  1; 

compoaite.part 

at  0 

range  coro.part.iizo  ..  coBpotite.vidget.tize  -  1; 
tholl.part 
at  0 

range  coBpotite.vidget.tize  ..  thell.vidget.eize  -  1; 
override.thell.part 
at  0 
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rang*  shell.vidget.size  . .  override_shell.vidget.size  -  1; 
vm.shell.part 
at  0 

rang*  override.shell.vidget.size  ..  vm.shell.vidget.size  -  1; 
vendor.shell.part 
at  0 

rang*  vm.shell.vidget.size  . .  vendor.shell.vidget.size  -  1; 

•nd  record; 

type  vendor.shell.part .pointer  ia  accaaa  vendor.shell.part _rec; 
typ*  vendor. shell.vidget .pointer  ia  accaaa  vendor.shell.vidget.rec; 

—  tranai*nt_ah*ll_vidg*t 

transient.shell_part_ree.size  :  constant  cardinal  :*  0; 
typ*  transient. ah*ll_part_r*c  is  r*cord 
null; 

•nd  record; 

transient. shell.vidget. size  :  constant  cardinal  :■ 

▼endor.shell.vidget.aize  *  transient.shell_part_rec.size; 
type  transient.shell.vidget.rec  is  record 
core.part  :  core.private . eore.part ; 

compos ite.part  :  composite_private.composite_part.rec; 
shell.part  :  shell.part.rec; 

override. ahell.part  :  override .shell.part.rec; 
vm_shell_part  :  «m_ ahell.part _rec ; 
vendor.shell.part  :  vendor.shell.part.rec; 
transient.ahell.part  :  transient. shell.part.rec; 

•nd  record; 

for  transient.shell.vidget.rec  use  record  at  mod  implementation.def ined; 
core.part 
at  0 

range  0  ..  core.part.size  -  1; 

composite.part 

at  0 

range  core.part.size  ..  composite.vidget.size  •  1; 
shell.part 
at  0 

range  composite.vidget.size  ..  shell. vidget.size  -  1; 
override. shell.part 
at  0 

range  shell.vidget.size  ..  override. ahell.vidget. size  -  i; 
vm.shell.part 
at  0 

range  override.shell.vidget.size  ..  vm.shell.vidget.size  ~  1; 
vendor.shell.part 
at  0 

range  vm.shell.vidget.size  ..  vendor.shell.vidget.size  ~  1; 
transient .shell.part 
at  0 
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rang*  ▼•ndor_shall.widgat.siza  ,..  transiant.shall.widgat.siza  -  1; 
and  racord; 

typa  transient .shall.part .pointer  is  aeeass  transient. shall.part.rac; 
type  transiant.shall.widgat.pointar  is  aeeass  transiant.shall_widgat.rae; 

—  top.laral.shall.widgat 

top.laval_shall_paxt_rac.siza  :  constant  cardinal  :*  implamantation.delinad; 
type  top_laval.shall_part.rac  is  raeord 
icon .name  :  zt .string; 
iconic  :  zt .boolean; 
and  racord; 

top_laval_shall.widgat.siza  :  constant  cardinal  :» 

transiant.shall.widgat.siza  ♦  top_laval_shall.part_rac.siza; 
typa  top.laval.shall.widgat.rae  is  raeord 
cora.part  :  cora_privata.cora.part; 

cosposita.part  :  coBposita_privata.coaposita_part.rac; 
shall.part  :  shall.part.rac; 

ovarrida.shall.part  :  ovarrida.shall_part.rac; 
wm.shall.part  :  wm_ shall.part.rac; 

▼andor.shall.part  :  vandor.shall.part.rac; 
transient .shall.part  :  transient .shall.part.rac; 
top.laval. shall.part  :  top_laval_shall.part.rac; 
and  racord; 

for  top.laval.shall.widgat.rae  nsa  raeord  at  Bod  iwplaBantation.daf inad; 
cora.part 
at  0 

range  0  ..  core .part .size  -  1; 
compos it a.part 
at  0 

range  cora.part.siza  ..  composita.widgat.siza  -  1; 
shall.part 
at  0 

range  compo6ita.widgat.siza  ..  shall.widgat.siza  -  1; 
ovarrida.shall.part 
at  0 

range  shall.widgat.siza  ..  ovarrida.shall.widgat.siza  -  1; 
wm.shall.part 
at  0 

range  ovarrida.shall.widgat.siza  ..  wm.shall_widgat.siza  -  1; 
▼andor.shall.part 
at  0 

range  wm.shall.widgat.siza  ..  vendor. shall.widgat.siza  -  1; 
transient .shall.part 
at  0 

range  vandor.shall.widgat.siza  ..  transiant.shall.widgat.siza  -  1; 
top.laval.shall.part 

it  0  , 

range  transiant.shall.widgat.siza  ..  top.laval_shall_widgat.sxza  -  1; 
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end  record; 

type  top.level.shell.part .pointer  is  access  top.level.shell.part _rec; 
typs  top.level.shell.vidget .pointer  is  access  top.level_shell_vidget.rec; 

—  applicaticr.shell.vidget 

applicstion_shsll.psrt_rse.sizs  : 

constant  cardinal  :*  iapleaentation.def ined; 
typs  application.shsll_part.rsc  is  rscord 
class  :  vidget. class ; 
the.xra. class  :  x.vindovs.xrm. class; 
arge  :  cardinal; 
argv  :  argv.typs; 
snd  rscord; 

applieation.shsll.widgst.siss  :  constant  cardinal  :■ 

top_lsvsl_shsll.vidgst.sizs  *  application. shsll.part.rsc.sizs; 
typs  application.shsll_vidgst.rsc  is  rscord 
cors.part  :  cors_privats.cors.part; 
conposits.part  :  coaposits_privats.coBposits_part.rse; 
shsll.part  :  shell .part _rsc; 
ovsrrids.shsll.part  :  override.shell_part.rec; 
va.shsll.part  :  va_8hsll.part.rsc; 
vsndor.shsll.part  :  vendor .shsll.part _rsc; 
transisnt.shsll.part  :  transisnt.shsll.part.rsc; 
top.lsvsl.shsll.part  :  top_lsvsl_shsll.part.rsc; 
applieation.shsll.part  :  application.shsll.part.rsc; 
snd  rscord; 

for  application.shsll.vidgst.rsc  use  rscord  at  aod  iapleaent at ion. defined; 
cors.part 
at  0 

range  0  ..  core .part. size  -  1; 
coapo site .part 
at  0 

range  core .part .size  ..  coaposits.vidgst.sizs  -  1; 
shsll.part 
at  0 

range  coaposits.vidgst.sizs  . .  shsll.vidgst.sizs  ~  1; 
ovsrrids.shsll.part 
at  0 

range  shsll.vidgst.sizs  ..  ovsrrids_shsll.vidgst.sizs  -  1; 
va_  shsll.part 
at  0 

range  override. shsll.vidgst.sizs  ..  va.shsll.vidgst.sizs  -  1; 
vsndor.shsll.part 
at  0 

range  va_shsll_vidgst_sizs  ..  vsndor_shsll.vidgst.sizs  -  1; 
transisnt.shsll.part 
at  0 

range  vsndor.shsll.vidgst.sizs  ..  transient. shsll.vidgst.sizs  -  1; 
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top.level.shell.part 
at  0 

rang*  transient.shell.widget.siz*  ..  top.level_shell_widget.siz*  -  1; 
application. shell.part 
at  0 

rang*  top.level_shell_widget.siz*  . . 

application_sh*ll_*idg*t_*iz*  -  i; 

•nd  r*cord; 

typ*  applieation.shell.part .pointer  i*  ace***  application.shell.part.rec; 
typ*  application.shell.widget.pointer  i*  access 

application_*h*ll_vidg*t_r*c ; 

—  define  class  records  for  shell  widget  classes 

—  shell. class 

shell. class.part.rec. size  :  constant  cardinal  :■  implementation.defined; 
typ*  shell. class.part.rec  is  record 
extension  :  x.windoss . caddr.t ; 
end  record; 

shell.class.paTt.siz*  :  constant  cardinal  :■ 

composite. class.part. size  ♦  shell_class.part.ree. size; 
type  shell.class.part  is  record 

cor*. class.part  :  core_private.core_class.part; 

composite.class.part  :  composite_private.composite_elass_part.rec; 
shell.class.part  :  shell.class.part _r*c; 
end  record; 

for  shell.class.part  us*  record  at  mod  implementation.defined; 
cor*  _  clas  s .part 
at  0 

rang*  0  ..  core.class.part.siz*  -  1; 
composite.class.part 
at  0 

rang*  core.class.part.siz*  ..  composite. class.part. size  -  1; 
shell.class.part 
at  0 

rang*  composite.class.part.siz*  . .  shell.class.part.siz*  ~  1; 
end  record; 

typ*  shell.class.part .pointer  is  access  shell.class.part.rec; 
typ*  shell.class.pointer  is  access  shell.class.part; 

--  override.shell.class 

override.shell. class.part .rec.size  : 

constant  cardinal  :*  implementation.defined; 
typ*  override.shell_class_part.rec  is  record 
extension  :  x. windows. caddr.t; 
end  record; 
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override.shell_class_part.size  :  constant  cardinal  :■ 

•kwll-class.part.size  ♦  override.shell_class_part_rec.size; 
typa  override.shell.class.part  it  record 

coro.class.part  :  coro_privats.coro_class.part; 
composite. class .part  :  composite.private.composite.class.part.rec; 
ahell.class.part  :  sholl.class.part.roc; 
ovorrido.sholl.class.part  :  override. sholl.class.part.roc; 
end  record; 

lor  ovorrido.sholl.class.part  nse  record  at  mod  implementation  defined; 
coro.class.part 
at  0 

range  0  ..  core.class.part.size  -  1; 
conposite.class.part 
at  0 

core.class.part.size  ..  coBposite.elass.part.size  -  1; 
shell. class  .part- 
at  0 

range  conposite.class.part. size  ..  shell.claso_part.size  -  1; 
override.shell.class.part 
at  0 

range  shell.class.part.size  ..  override.shell_class_part.size  -  1; 
end  record; 

type  override.shell.class.part.pointer  is 

access  override_shell_class.part.rec ; 
type  override.shell.class.pointer  is  access  override.shell.elass.part; 

—  vm.shell.elass 

wn.shell_class_part.rec. size  :  constant  cardinal  :•  inplenentation.def ined; 
type  vm.shell.class.part.rec  is  record 
extension  :  x.windovs . caddr.t ; 
end  record; 

vm.shell.class.part.size  :  constant  cardinal  :■ 

override.shell_class_part.size  ♦  sm_shell_class.part_rec.size; 
type  vm.shell.class.part  is  record 

coro.class.part  :  core.private. coro.class.part; 
conposite.class.part  :  conposito. private. conposite.class.part _rec; 
shell.class.part  :  shell.class.part.roc; 
override.shell_cla6S.part  :  override_shell.class_part.rec; 
vm.shell.class.part  :  vm.shell.class.part.rec; 
end  record; 

for  vm.shell_class.part  nse  record  at  mod  implementation.def ined; 
coro.class.part 
at  0 

range  0  ..  core.class.part.size  -  1; 
conposite.class.part 
at  0 
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rang*  core.class.part.size  ..  composite.class.part.size  -  1; 
shell.  cla* • .part 
at  0 

rang*  composite.class.part.size  ..  shell.class.part.size  -  1; 
override.shell.class .part 
at  0 

rang*  shell.class.part.size  ..  oT*rrid*_*h*ll_clai*_part_aiz*  -  1; 
wm.shell_class.part 
at  0 

rang*  oYerride.shell.elass.part.size  ..  wm.shell_class_part.size  -  1; 
•nd  r*cord; 

typ*  wm.shell.class.part.pointer  it  acc*>*  wm.shell.class.part.rec; 
typ*  wm.shell.elass.pointer  i*  access  wm.shell.class.pnrt; 

--  vendor.shell.class 

v*ndor_sh*ll.class.part.r*c.siz*  : 

constant  cardinal  :■  implementation. d*f in*d; 
typ*  Yendor.shell.class.part.ree  is  record 
extension  :  x.windows . caddr.t ; 

•nd  record; 

▼•ndor. shell. class.part.siz*  :  constant  cardinal  :* 

ni.shell.class.part.size  *  Tendor_shell_class.part.rec.size; 
type  Yendor.shell.class.part  is  record 

core.class.part  :  core_priyate.core_class.part; 

composite .class .part  :  composite.private.composite.class.part.rec; 
shell.class.part  :  shell.class.part.rec; 

override.shell.class.part  :  oTerride_shell.class_part.rec; 

«m_ shell. class .part  :  wm.shell_class_part.rec; 
rendor. shell.class.part  :  Tendor.shell_class_part.rec; 

•nd  record; 

for  yendor.shell.class.part  use  record  at  mod  implementation.def ined; 
core.class.part 
at  0 

range  0  ..  core_class.part.size  -  1; 
composite. class .part 

at  0 

range  core.class.part.size  ..  composite.class.part.size  -  1; 
shell.class.part 
at  0 

range  composite.class.part.size  ..  shell.class.part.size  ~  1; 
override.shell.class.part 
at  0 

range  shell.class.part.size  ..  oyerride.shell.class.part.size  -  1; 
wm.shell_class.part 

at  0  , 

range  oyerride.shell.class.part.size  ..  wm.shell_class_part.size  ~  1; 

rendor. shell. class .part 
at  0 
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rang*  wm.shell.class.part.size  . . 

vendor.shell.class.part.size  -  1; 

•nd  record ; 

type  vendor.shell.class.part.pointer  it  access  vendor.shell.class.part.rec; 
type  vendor.shell.class.pointer  is  access  vendor. shell. class .part ; 

--  transient.shell.class 

transient. shell. class.part.rec.size  : 

constant  cardinal  :■  implementation.defined; 

type  transient_shell.class.part.ree  is  record 
extension  :  x. windows . caddr.t ; 
end  record; 

transient. shell. class. part .size  s  constant  cardinal  :• 

vendor.shell_class_part.size  *  transient. shell_class_part.rec.size; 
type  transient.shell.class.part  is  record 

core.class.part  :  core_private.core_class.part; 

composite. class .part  :  composite. private. composite. elass.part.rec; 
shell.class.part  :  shell. elass.part.rec; 
override.shell.elass.part  :  override_shell_class.part.rec; 
wm.shell.class.part  :  wm.shell. elass.part.rec; 
vendor. shell. class .part  :  vendor.shell_class_part.rec; 
transient.shell.class.part  :  transient_shell.class_part.ree; 
end  record; 

for  transient.shell.class.part  use  record  at  mod  implementation.def ined; 
core.class.part 
at  0 

range  0  ..  core.class.part.size  *  1; 
composite. class .part 
at  0 

range  core.class.part.size  . .  composite_class.part.size  -  1; 
shell.class.part 
at  0 

range  composite.class.part.size  ..  shell.class.part.size  -  1; 
override.shell.elass.part 
at  0 

range  shell.class.part.size  ..  override.shell_class_part.size  -  1; 
vm_  shell.class .part 
at  0 

range  override.shell.class.part.size  ..  wm.shell.class.part.size  -  1; 
vendor. shell.class.part 
at  0 

range  wm.shell.class.part.size  . . 

vendor_shell.class_part.size  -  1; 
transient.shell.class.part 
at  0 

range  vendor.shell_class_part.size  .. 

transient.shell.class.part. size  -  1; 
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•nd  re cord; 

type  transient.shell.class.part.pointer  is 

access  transient.shell_class_part.rec; 
type  transient.shell.class.pointer  is 

access  transient. shell.class.part; 


—  top.level.shell.class 

top.level_shell_class_part_rec.size  : 

constant  cardinal  :■  implementation.def ined; 
type  top.level.shell.class.part.rec  is  record 
extension  :  x.vindovs . caddr.t ; 
end  record; 

top.level.shell.class.part.size  :  constant  cardinal  :* 

transient.shell_class.part .size  *  top.level.shell.class.part.rec. size; 
type  top_level_shell.class.part  is  record 

core.class.part  :  core_private.eore_elass.part; 

composite.elass.part  :  composite.private. composite. elass.part.ree; 
shell.class.part  :  shell. elass.part.ree; 

override_shell.class.part  :  override. shell. elass.part.ree; 
ra_shell.class.part  :  ra.shell_elass_part.rec; 
vendor.shell.class.part  :  vendor.shell_class_part.rec; 
transient.shell.elass.part  :  transient.shell_class_part.rec; 
top.level_shell_class.part  :  top.level.shell.class.part.rec; 
end  record; 

lor  top.level_shell_class.part  use  record  at  mod  implementation.deiined; 
core.class.part 
at  0 

range  0  . .  core.class_part.size  -  1; 
compos ite.class .part 
at  0 

range  core.class.part.size  ..  composite.class.part.size  ~  1; 
shell.class.part 
at  0 

range  composite.class.part.size  ..  shell.class.part.size  -  1; 
override. shell. class .part 

at  0 

range  shell.class.part.size  ..  override.shell.class.part.size  -  1; 
ra_ shell.class.part 
at  0 

range  override.shell.class.part.size  ..  ra.shell_class_part.size  -  l; 
vendor.shell.class.part 
at  0 

range  ra.shell_class_part.size  . . 

vendor_shell_class.part.size  -  1; 
transient.shell.elass.part 
at  0 

range  vendor.shell.class.part.size  . . 

transient.shell_class_part.size  -  1; 
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t  op.level.  shall,  das  s  .part 
at  0 

rang*  transient. shell.class.part.siz* 
top_l*v*l.sh*ll_elass. part. sir* 

•nd  record; 


type  top.level.shell.class.part.pointer  is 

access  top.level_shell_class_part.rec ; 
type  top.level.shell.class.pointer  is 

access  top_l*v*l_sh*ll_elass_part; 


—  application.shell.class 

application.skell_class_part_rec.siz*  : 

constant  cardinal  :«  implement at ion.def ined; 
type  application_shell_class.part.rec  is  record 
extension  :  x.windovs . caddr.t ; 
end  record; 


top.level.shell.class.part.siz*  ♦  application.shell_elass_part_rec.size; 
type  application.shell.class.part  is  record 

core.elass.part  :  core_private.core_class.part; 

composite.class.part  :  compos ite.private. eomposite.class.part.ree; 
shell. class .part  :  shell_class.part.rec; 
override.shell.class.part  :  override_shell_class.part.rec; 
wm.shell_class.part  :  wm_shell_class.part.rec; 
vendor.shell_elass.part  :  vendor_shell_elass.part.ree; 
transient. shell.class.part  :  transient.shell_class_part.ree; 
top_level.shell_elass.part  :  top_level.shell.class_part.rec; 
application.shell.class.part  :  application.shell.class_part.rec; 
end  record; 


for  application.shell.class.part  us*  record  at  mod  implement at ion.def ined; 
core.elass.part 
at  0 

rang*  0  ..  core.class.part.siz*  -  1; 
composite.class.part 
at  0 

rang*  core.class.part.siz*  ..  composite.class.part. size  -  1; 
shell.class.part 
at  0 

rang*  composite.class.part.siz*  ..  shell.class.part.siz*  ~  1; 
override.shell.class.part 
at  0 

rang*  shell.class.part.siz*  ..  override.shell.class.part. size  -  1; 
wm_shell.class.part 
at  0 

rang*  override. shell.class.part.siz*  ..  wm.shell_class_part.siz*  -  1; 
vendor. shell.class.part 
at  0 

rang*  wm_shell_class.part.siz*  .. 

▼endor.shell_class_part.size  -  1; 
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transient .shell. class .part 
at  0 

rang*  vendor.shell_class_part.size  . . 

transiant_thall.class_part.aiza  -  1; 
top.level_shell_class.part 
at  0 

range  transiant.shall_class_part.siza  . . 

top.laval_shall_class_part.siza  -  1; 
appli cat ion. shall. clas s .part 
at  0 

range  top.laval.shall.class.part.siza  . . 

application.shall_class_part.siza  -  1; 

and  record; 

type  application.shall.class.part.pointar  is 

access  applieation.shall.class.part.rac  j 
type  applieation.shall.elass.pointar  is 

access  application_shall.class.part ; 


—  allocate  the  class  constant 

function  to.vidgat.class  is  nas  unchaekad_convarsion( 
source  •>  shall. class.pointar, 
target  ■>  sidgat. class) ; 

tha.shall.class  :  constant  vidget.class  :■ 
to.sidgat.class  (na*  shell.class.part) ; 

function  to.sidgat.class  is  nas  unchecked.conversionC 
source  »>  override. shell.class.pointer, 
target  ■>  sidgat. class); 

tha.ovarrida.shall.class  :  constant  sidgat.class  :■ 
to.sidgat.class  (nas  ovarrida.shall_class.part) ; 

function  to.sidgat.class  is  nas  unchecked. conversion( 
source  *>  sm.shall.class.pointar, 
target  *>  sidgat.class); 

tha.sa_shall_class  :  constant  sidgat.class  :■ 
to.sidgat.class  (nas  sm_shall_class_part) ; 

function  to.sidgat.class  is  nas  unchecked.conversionC 
source  *>  vendor.shell.class.pointer, 
target  *>  sidgat.class) ; 

tha.vandor.shall.class  :  constant  sidgat.class  :« 
to.sidgat.class  (nas  vandor.shall.class.part) ; 

function  to.sidgat.class  is  nas  unchecked_conversion( 
source  ■>  transient .shell.class.pointer, 
target  ■>  sidgat.class); 
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the.transient.shell.class  :  constant  vidgat.class  :■ 
to.widgat. class  (new  transient.shell.class.part) ; 


function  to.vidgat.class  is  new  unchecked. convers ion ( 
source  ■>  top.level.shell. class .pointer, 
targat  •>  vidgat.class); 


the.top.level.shell.class  :  constant  vidgat.class  :* 
to.widgat. class  (nav  top.laval_shall_class.part) ; 

function  to.vidgat.class  is  nav  unchecked_conversion( 
sourca  ■>  application.shall.class.pointar, 
targat  ■>  vidgat.class); 


tha.application.shall.class  :  constant  vidgat.class  :• 
to.vidgat.class  (nav  application.shall.class.part) ; 


and  shell.private; 


4.5  Pop-Up  Widgets 

The  package  specification  zt.geomztry .management  defines  the  types  and  subprograms  spec¬ 
ified  in  chapter  6  of  [3].  The  semantics  are  unchanged. 

package  xt .geometry .nanag ament  is 


type  xt.gaomatry.rasult 
(xt.geometry.yes , 
xt_gaomatry.no . 
xt .geometry .almost, 
xt.gaomatry.dona) ; 


is 


type  xt.stack.moda  is 
(xt. above, 
xt .below, 
xt_top.il , 
xt_bottom_if , 
xt.opposita, 
xt.dont. change) ; 


Above  in  x_lib_.a  Stack.Hoda.Typa 
Balov  in  x_lib..a  Stack.Hoda.Typa 
Top.If  in  x_lib_.a  Stack.Hoda.Typa 
Bottom_If  in  x_lib_.a  Stack.Hoda.Typa 
Opposite  in  x_lib_.a  Stack.Hoda.Typa 
not  in  x.lib_.a 


subtype  xt. geometry .mask  is  x.vindovs.boolaan.array  (0  ..  7); 


type  xt .widget .geometry  is  recdrd 
raquast.moda  :  xt. geometry .mask; 
x,  y  :  position; 

width,  height,  bordar.vidth  :  dimension; 
sibling  :  widget; 
stack.moda  :  xt.stack.moda; 
and  record; 

xt.null.gaomatry.mask  :  constant  xt.gaomatry.mask  :■ 
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_  xt.geometry .mask’ (others  »>  false); 
xt_c*_x  :  constant  xt.geometry.mask  :« 

xt.geometry.mask’ (0  ■>  trna,  others  *>  false); 
xt.cw.y  :  constant  xt.geometry.mask  :■ 

xt.geometry.mask* (1  ■>  true,  others  ■>  false); 
xt.cw.width  :  constant  xt .geometry .mask  :■ 

xt .geometry .mask' (2  ■>  true,  others  »>  false); 
xt.cw.height  :  constant  xt.geometry.mask  :■ 

xt. geometry .mask’ (3  ■>  true,  others  ■>  false); 
xt.cw.border .width  :  constant  xt.geometry.mask  :■ 

xt.geometry.mask' (4  ■>  true,  others  »>  false); 
xt.cw.sibling  :  constant  xt.geometry.mask  :■ 

xt.geometry.mask' (S  ■>  true,  others  ■>  false); 
xt.cv.stack.mode  :  constant  xt.geometry.mask  :■ 

xt.geometry.mask' (6  ■>  true,  others  ■>  false); 
xt.cv.query.only  :  constant  xt.geometry.mask  : ■ 

xt.geometry.mask' (7  ■>  true,  others  ■>  false); 

procedure  xt_make.geometry.request 
(*  t  widget ; 

request  :  in  out  xt.widget .geometry; 

reply. return  :  in  out  xt.widget .geometry; 

result  :  out  xt.widget.geometry) ; 

procedure  xt.make.resize.request 
Cw  :  widget; 

width,  height  :  dimension; 

width.retum,  height.return  :  out  dimension; 

result  :  out  xt .geometry .result) ; 

procedure  xt.mo we .widget  (w  :  widget; 

x,  y  :  position); 

procedure  xt.resize.widget  (w  :  widget; 

width,  height  ;  dimension; 
border.width  :  dimension); 

procedure  xt.conf igure.widget  (w  :  widget; 

x,  y  :  position; 

width,  height  :  dimension; 

border.width  :  dimension); 

procedure  xt.re6ize_window  (w  :  widget); 

procedure  xt.query.geometry 

(w  :  widget; 

intended  :  xt.widget.geometry; 

preferred.return  :  out  xt.widget.geometry; 

result  :  xt.geometry.result) ; 
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end  xt .geometry .management; 
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Three  procedure  types  axe  needed  by  ^geometry  management.  The  first  is  the  resize 
procedure  which  is  of  the  previously  defined  type  zt.widget.proc.  The  remaining  two,  geom- 
etry.manager  and  query.geometryy  are  of  type  zt-geometry. handler. 

pseudo.type  xt.geometry .handler  is 

ns*  proc.type (request  :  xt.widget.geometry; 

geometry.retura  :  xt.widget.geometry) 
return  xt.geometry.result; 

4.6  Geometry  Management 

The  package  specification  zt.geometry.management  defines  the  types  and  subprograms  spec¬ 
ified  in  chapter  6  of  [3].  The  semantics  are  unchanged. 

package  xt.goometry .management  is 

type  xt.geometry.result  is 
(xt.geometry.yes , 
at_geometry.no, 
at.geometry.almost , 
at .geometry .done) ; 

type  xt_stack_mode  is 

(xt.above,  —  Above  in  x_lib_.a  Staek.Node.Type 

xt .below,  —  Below  in  x_lib_.a  Staek.Node.Type 

xt.top.if,  —  Top.If  in  x.lib_.a  Staek.Node.Type 

xt.bottom_if ,  —  Bottom.Xf  in  x_lib_.a  Staek.Node.Type 

at.opposite,  —  Opposite  in  x.lib_.a  Staek.Node.Type 

xt.dont.ehange) ;  —  not  in  x.lib..a 

subtype  xt.geometry.mask  is  x.windows . boolean.array  (0  ..  7); 

type  xt .widget .geometry  is  record 
request .mode  :  xt.geometry.mask; 
x,  y  :  position; 

width,  height,  border.width  :  dimension; 
sibling  :  widget; 
stack.mode  :  xt.stack.mode; 
end  record; 

xt.null.geometry.mask  :  constant  xt.geometry.mask  :■ 

xt.geometry.mask' (others  ■>  false); 
xt.cw.x  :  constant  xt.geometry.mask  :■ 

xt.geometry.mask ’(0  ■>  true,  others  *>  false); 
xt.cw.y  :  constant  xt .geometry .mask  :■ 

xt.geometry.mask' (1  *>  true,  others  ■>  false); 
at.cw.width  :  constant  xt.geometry.mask  ;■ 

xt.geometry.mask' (2  ■>  true,  others  «>  false); 
at.cw.height  ;  constant  xt.geometry.mask  :• 

xt.geometry.mask’ (3  ■>  true,  others  ■>  false); 
xt.cw.border. width  :  constant  xt.geometry.mask  :• 
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xt.geoBetry.aask* (4  «>  true,  others  ■>  false); 
xt.ew.sibling  :  constant  xt.geoaetry.Bask  : * 

xt.geoaetry.Bask* (6  ■>  true,  others  ■>  false); 
xt_cw.stack.Bode  :  constant  xt.geoBetry.aask  :■ 

xt.geoaetry.Bask’ (6  ■>  true,  others  ■>  false); 
xt.cw.query.only  :  constant  xt.geoaetry.Bask  :* 

xt.geoBetry.aask’ (7  «>  true,  others  ■>  false); 

procedure  xt.aake.geoaetry.request 
(w  :  widget ; 

request  :  in  out  xt .widget .geoaetry; 

reply.return  :  in  out  xt.widgat.geoaetry; 

result  :  out  xt.widget.geoaetry) ; 

procedure  xt.aake.resize.request 
(w  :  widget; 

width,  height  i  dinenslon; 

width. return,  height. return  :  out  diaension; 

result  :  out  xt.geoaetry .result) ; 

procedure  xt.aove_widget  (w  :  widget; 

x,  y  :  position); 

procedure  xt.resize.widget  (w  :  widget; 

width,  height  ;  dimension; 
border.width  :  dimension); 

procedure  xt.conf igure.widget  (w  :  widget; 

x,  y  :  position; 

width,  height  :  dimension; 

border.width  :  dimension); 

procedure  xt.resize.window  (w  :  widget); 

procedure  xt.query.geometry 

(w  :  widget; 

intended  :  xt.widget.geoaetry; 

preferred.return  :  out  xt.widget.geoaetry; 

result  :  xt .geoaetry .result ) ; 

end  xt.geometry .management; 

Three  procedure  types  are  needed  by  geometry  management.  The  first  is  the  resize 
procedure  which  is  of  the  previously  defined  type  xt.widget.proc.  The  remaining  two,  geom¬ 
etry-manager  and  query  .geometry ,  are  of  type  xt.geometry.handler. 

pseudo.type  xt.geometry.handler  is 

new  proc.type (request  :  xt.widget.geometry; 

geometry .return  :  xt.widget.geometry) 
return  xt.geoaetry.result; 
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4.7  Event  Management 

The  following  package  specification  defines  the  event  management  types  and  subprograms 
with  semantics  as  described  in  chapter  7  of  [3]. 

package  xt.event .management  is 

type  xt .event .table  is  private; 

type  interval.type  is  implementation.def ined; 

type  device  is  implementation.def ined; 

--  xt  types 

subtype  xt. input .mask  is  x.vindovs .boo lean. array  (1  ..  32); 

xt.im.xevent  :  constant  xt.input.aask  :■ 
xt. input .Bask' (1  ■>  true, 

others  *>  false); 

xt.ia.tiaer  i  constant  xt. input. mask  «■ 
xt. input .Bask' (2  ■>  true, 

others  ■>  false) ; 

xt.im. alternate .input  :  constant  xt.input.aask  : ■ 
xt. input .Bask* (3  ■>  true, 

others  ■>  false); 

xt. input .read.aask  :  constant  xt. input .Bask  :■ 
xt. input .Bask’ (4  *>  true, 

others  *>  false); 

xt. input .write .aask  :  constant  xt.input.aask  :• 
xt _ input .ansk’ (6  «>  true, 

others  ■>  false); 

xt_input.except.aask  :  constant  xt. input _aask  :» 
xt. input .mask' (6  *>  true, 

others  ■>  false); 


function  xt.app.add.input  (app.context 

source 

condition 

proc 

client .data 


application.context ; 
device; 

xt.input.aask; 
xt_input.callback.proc ; 
x.vindovs . caddr.t ) 
return  xt.input.id; 


function  xt.app.add.timeout  (app.context 

interval 

proc 

client.data 


:  application.context; 

:  interval.type; 

:  xt.timer.callback.proc; 
:  x.vindovs .caddr.t) 
return  xt.interval.id; 


procedure  xt.remove.timeout (timer  :  in  xt.interval.id); 

procedure  xt.add.grab  (v  :  vidget; 

exclusive,  spring.loaded  :  boolean); 

procedure  xt. remove. grab  (v  :  vidget); 
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procedure  zt.set.keyboard.focus  (eubtree,  descendant  :  widget); 

function  zt.call.accept .focus  (w  :  widget; 

t  :  z.windows .time)  return  boolean; 

function  zt.app.pending 

(app.contezt  :  application.contezt)  return  xt_ input .mask; 

procedure  zt.app.peek.event  (app.contezt  :  application.contezt; 

event.return  :  out  z.event; 
event. found  :  out  boolean); 

procedure  zt.app.nezt.event  (app.contezt  :  application.contezt; 

event.return  :  out  z.event); 

procedure  zt.app.process.event  (app.contezt  :  application.contezt; 

Bask  :  zt_ input .Bask) ; 

function  zt.dispatch.event  (event  :  z.event)  return  boolean; 

procedure  zt.app.aain.loop  (app.contezt  :  application.contezt); 

procedure  zt. set. sensitive  (w  :  widget; 

sensitive  :  boolean); 

function  zt.is. sensitive  (w  :  widget)  return  boolean; 

procedure  zt_app_add_work.proc(app.contezt  :  application.contezt; 

proc  .*  zt.work.proc; 

client.data  :  z.windows. caddr _t ) ; 

procedure  zt.remove.work.proc  (proc:  zt.work.proc); 

procedure  zt.add.event .handler 

(w  :  widget; 

an. event .aask  :  event .Bask; 
non.aaskable  :  boolean; 
proc  :  zt. event .handler.proc; 

client.data  :  z.windows. caddr.t); 

procedure  zt.renove. event .handler 

(*  :  widget ; 

an.event.nask  :  event .Bask; 
non.aaskable  :  boolean; 
proc  :  zt .event. handler .proc; 

client.data  :  z.windows. caddr.t) ; 

procedure  zt.add.raw.event.handler 

(w  :  widget ; 

an.event.mask  :  event .aask; 
non.aaskable  :  boolean; 
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proe 

client.data 


xt .event .handler.proc ; 
x.windows . caddr.t ) ; 


procedure  xt.remove.raw.event .handler 

Cw 

an. event  .mask 

non.maskable 

proe 

client.data 


widgat ; 

•rant .mask; 
boolean; 

xt. event. handler .proe ; 
x_ windows . caddr.t ) ; 


function  xt_build.event.aask  (w  :  widget)  return  event.mask; 
private 


implement at ion.dex ined 


end  xt.event .management; 

The  following  procedures  types  are  defined  for  event  management: 


pseudo.type  xt.input. callback. proe  is 

new  proe.typeCelient.data 
source 


id 


x.windows . caddr.t ; 
device; 
xt.input. id) ; 


pseudo.type  xt.timar_callback.proc  is 

new  proe.typeCelient.data 
id 

pseudo.type  xt .accept .focus .proe  is 

new  proe .type (the .widget 
the.time 


pseudo.type  xt.work.proc  is 

new  proe.typeCelient.data 


:  x.windows . caddr.t ; 

:  xt.interval.id) ; 

:  widget; 

:  x.windows. time) 
return  boolean; 

:  x.windows. caddr.t) 
return  boolean; 


pseudo.type 


xt.expose.proc  is 

new  proc.typeCthe. widget 
tbe.event 
the.region 


in  out  widget; 
x.event ; 
x.region) ; 


pseudo.type  xt_event.handler.proc  is 

new  proc.typeCthe. widget  :  widget; 

client .data  :  x.windows . caddr.t ; 
the.event  :  x.windows. events. event); 


4.8  Callbacks 

The  package  specification  zLcallbacks  defines  the  types  and  subprograms  associated  with 
callbacks.  The  semantics  of  the  subprograms  are  as  described  in  chapter  8  of  [3].  In  the 
Ada  specification  objects  of  type  xt.callback-list  differ  from  the  C  specification  in  that  lists 
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should  not  be  null  terminated.  For  this  reason  we  have  changed  the  C  procedure  names  for 
XtAddCallbacks  and  XtRcmovcCallbacks  to  zt.add-callback-list  and  zt.remove  .callback-list 
respectively.  The  functionality  of  these  procedures  remains  the  same. 


package  xt. callbacks  is 

type  xt.callback.status  is 
(xt.callbaek.no.list, 
xt  _ callback .has .none , 
xt.callback.has.some) ; 

type  xt.callback.rsc  is  record 

callback  :  xt.callback.proc; 
closure  :  x. windows . caddr.t ; 
end  record; 

type  xt.callback.list  is  array  (natural  range  <>)  of  xt.eallbaek.ree; 
type  xt.callback.list.ptr  is  access  xt.callback.list; 


procedure  xt.add.callback  (w  :  widget; 

callback.naae  :  string; 

callback  :  xt.callback.proc; 

client .data  :  x_ windows. caddr.t); 


procedure  xt.add_callbaek.list 


(w 

callback.naae 

callbacks 


widget ; 
string; 

xt.callback.list) ; 


procedure  xt .remove. callback 


(* 

callback.naae  : 

callback 

client.data 


widget ; 
string; 

xt.callback.proc ; 
x. windows . caddr.t) ; 


procedure  xt.reaove.callback.list  (w  :  widget; 

callback.naae  :  string; 
callbacks  :  xt.callback.list); 


procedure  xt.reaove.all.callbacks  (w  :  widget; 

callback.naae  :  string); 

procedure  xt.call. callbacks  (w  :  widget; 

callback.naae  :  string; 
client.data  :  x.windows. caddr.t ) ; 


function  xt.has.callbacks 

(w  :  widget ; 

callback.naae  :  string)  return  xt.callback.status; 
end  xt.callbacks; 


The  procedure  type  xt.callback.proc  is  defined  in  the  following  package  specification; 
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pswudo.typ*  xt.callback.proc  is 

n«s  proc_typ«(th*_vidg«t 
client. data 
call.data 


in  widgat; 
x.windows . caddr.t ; 
x.windows . caddr.t) ; 


4.9  Resource  Management 

4.0.1  Interface  to  Resources 

A  difficult  problem  arose  in  specifying  the  interface  to  argument  lists  for  several  of  the  re¬ 
source  management  subprograms.  The  C  model,  lacking  function  overloading,  creates  lists  of 
untyped  data  (lists  of  many  different  types  stored  as  a  single  type).  This  can  be  done  in  Ada 
but  at  the  cost  of  requiring  application  and  widget  programmers  to  do  unchecked-conversions 
to  the  list  type.  A  solution  is  to  provide  a  generic  package  which  provides  functions  to  relieve 
programmers  of  the  conversion  task. 

The  generics  solution  is  not  problem  free.  In  implementing  the  generics,  we  discovered 
that  some  compilers  (TeleSoft)  do  not  permit  unchecked-conversion  of  unconstrained  types, 
and  retrieving  values  of  unconstrained  types  may  not  be  possible.  Arrays  in  Ada  (this  is 
generally  true  with  any  unconstrained  Ada  type)  may  have  additional  bytes  added  to  the 
array  to  provide  indexing  and  size  information.  In  retrieving  data  the  intrinsics  do  not 
know  the  type  of  the  data,  and  retrieve  data  based  solely  on  location  and  size.  The  Telesoft 
compiler  added  three  words  to  the  front  of  unconstrained  arrays  (which  are  not  counted  in 
the  ’length  attribute)  making  it  impossible  to  retrieve  the  value  without  making  assumptions 
about  a  specific  compiler’6  handling  of  arrays. 

The  Ada/Xt  implementation  imposes  the  additional  restriction:  resource  types  which  are 
unconstrained  types  such  as  arrays,  and  variant  and  discriminant  records,  are  not  supported. 
One  unconstrained  type,  string,  U  required  in  Xt,  but  since  the  intrinsics  know  about  string 
types  a  test  for  a  resource  of  type  string  is  made  when  retrieving  a  resource  value.  String 
types  have  separately  defined  subprograms  for  setting  and  retrieving  values. 

The  solution  also  falls  short  in  retrieving  resource  values  because  it  requires  the  user  to 
use  ’address  to  provide  a  memory  address  for  storing  the  retrieved  data.  This  allows  the 
intrinsics  to  simply  copy  data  (of  an  unknown  Ada  type)  from  the  resource  field  to  a  user  s 
local  data  space  without  needing  to  know  about  the  underlying  type.  However,  this  is  an 
unfortunate  use  of  system-dependent  programming,  and  is  in  fact  a  bit  “unsafe.” 

Another  approach  to  building  argument  lists  might  be  to  set  resource  values  individually, 
but  not  have  them  take  effect  immediately.  A  new  activate  procedure  could  then  initiate  the 
changes  to  the  actual  widget  resources.  This  approach  fails  because  the  design  of  Xt  permits 
use  of  the  set.values.hook  function  for  setting  subpart  resource  values.  Individual  setting  of 
resource  values  requires  changing  the  interface  to  the  set-values-hook  procedure  which  is  not 

The  following  package  specifications  define  the  generic  interface  to  these  untyped  lists, 
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and  subprograms  for  setting  and  retrieving^tnnp  resource  values. 

package  resource.values  is 

subtype  xt.arg.val  isx.vindows . eaddr.t ; 
type  xt.arg  is 
record 

name  :  zt .string; 
value  :  zt.arg.val; 
end  record; 

type  arg.list  is  array  (natural  range  <>)  of  xt.arg; 
type  arg.list.ptr  is  access  arg.list; 

type  zt.convert.arg  is 
record 

address.mode  :  zt.address.mode; 
address.id  :  x. windows. eaddr.t ; 
size  :  cardinal; 

end  record; 

type  zt. convert. arg.list  is  array  (natural  range  <>)  of  zt.convert.arg; 

type  zrm. value  is 
record 

size  :  z.windovs .x.integer; 
address  :  z.windovs . eaddr.t ; 
end  record; 

type  zrm. value _ptr  is  access  zrm. value; 

type  xrm_value_ptr_list  is  array  (natural  range  <>)  of  zrm.value.ptr; 

procedure  zt.set.arg  (erg  :  in  out  xt.arg; 

name  :  in  string; 

value  :  in  system. address) ; 

procedure  zt.set.arg  (erg  :  in  out  xt.arg; 

name  :  in  string; 

value  :  in  string); 

function  set_convert_arg(mode  :  in  zt.address.mode; 

size  :  in  cardinal; 
res  :  in  system. address) 

return  zt.convert.arg; 


function  set_xrm_value(size  :  cardinal; 

res  :  system. address)  return  zrm. value; 

function  zt.merge.arg.lists  (argsl,  ergs 2  :  arg.list)  return  arg.list; 

generic 

type  resource.type  is  private; 
resource.size  :  in  out  cardinal; 
package  resource.interface  is 

procedure  zt_set_arg(arg  :  in  out  xt.arg; 

name  :  in  string; 

res  :  in  resource.type); 
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function  set.convert.argCmode  :  xt_ address .mode; 

res  :  resource .type) 

return  xt_ convert _arg; 


function  set.convert_arg(position  :  in  integer; 

rot  :  resource.type) 

return  xt.convert.arg; 


function  init_xrm_resouree(name  :  in 

class  :  in 
rtype  :  in 
size  :  in 
offset  :  in 
dtype  :  in 
deddr  :  in 
return 


string; 

string; 

string; 

cardinal; 

cardinal; 

string; 

resource.type) 
xrm_resouree_ptr ; 


end  resource. interface; 
end  resource.values; 

4.9.2  Representation  of  Resource  Lists 

Another  major  difference  of  the  C  and  Ada  specifications  in  resource  management  is  the 
representation  of  resource  lists.  In  C  resource  lists  are  initially  represented  as  XtReaource 
with  string  values  for  the  various  resource  names.  This  is,  in  part,  due  to  C’s  inability  to 
execute  conversion  functions  during  aggregate  array  initialization.  Ada  can  do  the  conversion 
to  XrmReaource  during  aggregate  initialization.  Furthermore,  C  does  an  in  place  conversion 
of  the  resource  list  in  the  widget  class  data  structure  which  violates  Ada’s  strong  typing. 
As  a  result,  the  Ada  specification  defines  resource  lists  to  be  of  type  xrm.reaource.Jist  in  the 
widget  class  structure  and  provides  conversion  functions  to  create  the  proper  lists.  Several 
conversion  functions  are  provided  to  allow  conversion  to  the  xt.reaource  type. 

type  xt .resource  is 
record 

resource.name 
resource. class 
resource.type 
resource. size,  resource 
default .type 
default .address 
end  record; 

type  xt.resource.ptr  is  access  xt. resource; 

type  xnn.resource  is 
record 

resource.name 
resource.class 


:  xt.string; 

:  xt.string; 

:  xt.string; 

.offset  :  cardinal; 

:  xt.string; 

:  x.vindovs.caddr.t; 


x.vindoes . xrm.name ; 
x.windows .xrm.class; 
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rasourca.typa 

rasourca.siza,  rasourca.off sat 
default .typa 
default .address 
•nd  record; 


x_ windows . xn_  quark ; 
cardinal; 

x_ windows . xn_ quark ; 
x.windoss . caddr.t ; 


type  xn.rasourca.ptr  is  accass  xn.rasourca; 


typa  xt.rasourca.list  is  array  (natural  range  <>)  of  xt.rasourca; 
typa  xt.rasourca_list.ptr  is  accass  xt.rasourca.list; 


typa  xn_rasourea_list  is 

array  (natural  ranga  <>)  of  xn.rasourca.ptr; 
typa  xn.rasourca_list.ptr  is  accass  xn.rasourca.list; 

function  craata.xn.rasourca  (resource  :  xt.rasourca) 
return  xn.rasourca; 

function  eraata.xn.rasourca.list 

(rlist  :  xt.rasourca.list)  return  xn.rasourca.list.ptr; 

function  craata.xt.rasourea.list 

(rlist  :  xn.rasourca.list)  return  xt.rasourca.list.ptr; 

function  create.xt.resource 

(resource  :  xn.rasourca)  return  xt.rasourca; 


function  xt.database 

(the.display  :  x. windows. display)  return  xn.database; 


procedure  xt_gat.rasourca.list 
(class 

resources.return 


widget. class; 

out  xt.rasourca.list.ptr) ; 


procedure  xn_get.resource.list 
(class 

resources.return 


widgat.class; 

out  xn_resource_list_ptr) ; 


4.9.3  Resource  Management  Package  Specification 

The  package  specification  zt.rcsourcejnanagement  defines  the  remaining  resource  manage¬ 
ment  subprograms.  These  coincide  with  the  definitions  in  chapter  9  of  [3]  except  for  the 
use  of  zrm.rtaourctJists  instead  of  zt.resourcc.lists.  The  procedure  zt.get-resourceJist  is 
overloaded  to  supply  either  the  list  in  “quarked”  form  or  in  string  form. 

packaga  xt.resource.management  is 

typa  xt .address .node  is 
(xt .address, 
xt.basa.off sat, 
xt. immediate, 
zt.rasourca.string , 
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xt.resource.quar k) ; 

type  xt.convert.arg  is 
record 

address .mode  :  xt.address.mode ; 
address .id  :  x.windows .caddr.t; 
size  :  cardinal; 

and  record; 

procedure  xt.get.subresources  (w  :  widgwt; 

base  :  x.windows . caddr.t ; 

nan*  :  string; 

class  :  string; 

resources  :  xrm.resource.list; 

ergs  :  arg.list); 

procedure  xt.get.application.resources  (w  t  widget; 

base  :  x.windows . caddr.t ; 

resources  :  xrn.resource.list; 

ergs  ;  arg.list); 

procedure  xt.string.conversion.waming  (sre,  dst.type  :  string); 

procedure  xt.app.add.conwerter 

(app.context  :  application.context ; 

lrom_type,  to.type  :  string; 

converter  :  xt _ convert er.proc; 

converter.args  :  xt. convert. arg.list) ; 

procedure  xt. convert  (w  :  widget; 

from.type  :  string; 

Iron  :  xxm.value.ptr; 

to.type  :  string; 

to  :  out  xrm.value.ptr); 

procedure  xt .direct. convert  (converter  :  xt. converter .proc; 

args  :  xrm.value_ptr.list; 

Iron  :  xrm. value _ptr; 

to.retum  :  out  xrm.value.ptr) ; 

procedure  xt.get.values  (w  :  widget; 

args  :  arg.list); 

procedure  xt.get.subvalues  (base  :  x.windows. caddr.t; 

resources  :  xrm.resource.list; 
args  :  arg.list); 

procedure  xt. set. values  (w  :  in  out  widget; 

args  :  arg.list); 

procedure  xt.set.subvalues  (base  :  x.windows. caddr.t; 

resources  :  xrm.resource.list; 
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•nd  xt.resource.management; 


args 


arg.list); 


The  following  procedures  types  are  defined  for  resource  management: 


psoudo.typo  xt.args.proc  is 

no*  proc.typeCthe.vidget  :  in  out  vidgot; 

the.arglist  :  arg.liat); 


psoudo.typo  xt.sot.valuo.func  is 

nos  proc_typo(curront_vidgot  :  in  vidgot; 

request.vidget  :  in  vidgot; 
nov.vidgot  :  in  vidgot) 
return  boolean: 


psoudo.typo  xt.almost.proc  is 

no*  proc_type(the_«idget  :  in  out  vidgot; 

nov.vidgot .return  :  out  vidgot; 

request,  reply  :  in  out  xt.vidgot.goomotry) ; 


psoudo.typo  xt.args.fune  is 

no*  proc_typo(the_*idget 
tho.arglist 


in  vidgot; 

arg.list)  return  boolean; 


psoudo.typo  xt.rosourco.dof ault.proc  is 
nos  proe.type (the. vidgot 
offset 
value 


in  out  vidgot; 
in  cardinal; 
in  out  xrs_ value); 


psoudo.typo  xt.convortor.proc  is 
nov  proc_typo(args 
from 


to 


in  xrm. value. list ; 
in  xrm. value; 
out  xrm. value); 


4.10  Translation  Management 

The  translation  management  subprograms  and  data  types  are  specified  in  the  following 
package  and  retain  the  same  semantics  as  specified  in  chapter  10  of  [3], 

package  xt.translatio&.managomo&t  is 

typo  xt.translations  is  implomontation.dof inod; 
typo  xt.accolorators  is  implomontation.dof inod; 


typo  xt.action.roc  is 
record 

action.namo  :  xt. string; 
action.proe  :  xt.action.proc; 
end  record; 

typo  xt.action.list  is  array  (natural  range  <>)  of  xt.action.roc; 
typo  xt.action_list.ptr  is  access  xt.action.list; 
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procedure  xt.app_add.acti.ons  (app.contaxt  :  ■'pplication.context ; 

actions  :  xt.action.list) ; 


function  xt.parse.translation.table 

(tabla  :  string)  return  xt.translations; 

procedure  xt_ augment .translations  (v  :  widget; 

translations  :  xt.translations); 


procedure  xt.override.translations  (w 

translations 


:  widget; 

:  xt.translations) ; 


procedure  uninstall.translations  (w  :  widget); 

function  xt.parse.accelerator.table 

(table  :  string)  return  xt.accelerators; 

procedure  xt.install.accelerators  (destination,  source  :  widget); 


procedure  xt.insvall.all.accelerators  (destination,  source  :  widget); 

procedure  xt.set.key.translator  (the .display  :  x.windows. display; 

proc  :  xt.key.proc) ; 
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procedure  xt.translate.keyeode 

(the .display  :  x.windows .display; 

the.keycode  :  x.windows. key code; 

some .modifiers  :  modifiers; 

modifiers. return  :  out  modifiers; 

keysym_retum  :  out  x.windows. key. sym) ; 

procedure  xt.register.case. converter 
(the .display  :  x.windows .display; 
proc  :  xt.case.proe; 

start,  stop  :  x_ windows. keyboard. key. sym) ; 

procedure  xt_ convert. case 

(the.display  :  x.windows .display; 

some.keysym  :  x.windows .key. sym; 

lower.return,  upper. return  :  out  x.windows. key.sym) ; 

end  xt.translation.management; 

The  following  procedure  types  are  specified  for  translation  management: 


pseudo.type 

xt.action.proc  is 

new  proc_type(the_widget 

:  in  out  widget; 

the.event 

:  in  x_ windows. x.event; 

params 

:  in  string; 

num.paraas 

:  cardinal); 

pseudo.type 

xt.string.proc  is 

new  proc_type(the_widget 

:  in  out  widget; 
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str 


xt. string) ; 


pseudo.type  xt.key.proc  is 

nsv  proc.type(the.display  :  x.vindovs . display ; 

the.keycode  :  x.vindovs. keycode; 

sods .modifiers  :  modifiers; 

modifiers .return  :  out  modifiers; 

keysym.return  :  out  x.vindovs. key.sym); 


pseudo.type  xt.case.proc  is 

new  proc.type(the.keysym  :  in  x.vindovs .key.sym; 

loser.return  :  out  x.vindovs .key.sym; 
upper.return  :  out  x.vindovs. key.sym) ; 


4.11  Utility  Functions 

Some  differences  exist  in  the  utility  functions  due  to  language  differences.  For  example, 
the  C  function  XtNumber  is  not  needed  in  Ada  because  Ada  provides  the  ’ length  array 
attribute.  The  memory  management  functions  may  not  be  used  in  the  same  way  as  in  a 
C  implementation  since  Ada  has  new  for  allocating  storage  for  its  pointer  types.  For  types 
the  intrinsics  does  not  know  about  (widgets),  memory  management  functions  are  necessary. 
The  memory  management  functions  return  an  implementation  defined  type  which  should  be 
some  form  of  address  to  the  allocated  storage.  The  remaining  subprograms  provide  the  same 
functionality  as  defined  in  chapter  11  of  [3]. 

The  following  types  are  assumed  to  be  visible  to  the  utilities  package,  and  could  be 
defined  in  this  package: 

type  ptr  is  implamantation.daf inad; 

typa  string.list  is  array  (natural  rang*  <>)  of  xt.string; 

The  following  package  defines  the  utility  interfaces  for  Ada/Xt: 

packags  xt.utilitiss  is 

--  translating  strings  to  vidget  instances : 

function  xt.nams.to.vidgst  (rsfsrsnco  :  vidget; 

names  :  string)  return  vidget; 


—  managing  memory  usage: 

function  xt.malloc  (size  :  cardinal)  return  ptr; 

function  xt.calloc  (num,  size  :  cardinal)  return  ptr; 

function  xt.realloc  (p  :  ptr; 

num  :  cardinal)  return  ptr; 
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procedure  xt.fr**  (p  :  in  out  ptr); 

—  sharing  graphics  contexts: 

function  xt_g*t_gc  (*  :  widget; 

value .mask  :  xt.gc.mask; 
values  :  x.windows. x.gc. values) 
return  x.vindovs . gc ; 

—  is  this  list  or  array? 

procedure  xt.release.gc  (v  :  widget; 

the.gc  :  x.vindovs .gc) ; 

—  Managing  selections: 

procedure  xt.app.set.selection.tiMeout 

(app.eontext  :  applieation.eontext; 
timeout  :  x.windows .tine) ; 

function  xt.app.get.select ion. timeout 

(app.eontext  :  applieation.eontext)  return  x.windows .time; 

procedure  xt.get.selection.valu* 

(*  :  widget; 

selection,  target  :  x.windows . atom; 

callback  :  xt_selection.callback.proc; 

client .data  :  x.windows . caddr.t ; 

timestamp  :  x.windows .time) ; 


procedure  xt.get.selection.valu** 

(* 

selection 

targets 

callback 


widget ; 

x.windows .atom; 
x.vindovs . atom.list ; 
xt_selection.callback.proc ; 


client .data  :  x.windows. caddr.t; 


timestamp 


x.vindovs .time) ; 


function  xt.ovn.selection 

(«  :  widget ; 

selection  :  x.windows. atom; 

timestamp  :  x.windows .time; 

convert _proc  :  xt.convert.selection.proc; 

lose.selection  :  xt.lose.selection.proc; 

done.proc  :  xt_selection.done.proc)  return  boolean; 

procedure  xt_disown_s*lection(v  :  widget; 

selection  :  x.vindovs .atom; 
timestamp  :  x.vindovs .time) ; 


—  merging  events  into  a  region 
procedure  xt.add.exposure.to.region 
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:  x.vindovs . event ; 
region  :  x.vindovs. region); 

—  translating  vidget  coordinates 

procedure  xt.translate.coords  (w  :  vidget; 

x,  y  :  position; 
rootx.return  :  out  position; 
rooty.retum  :  out  position); 


—  translating  a  window  to  a  widget 

function  xt.windov.to.vidget 

(the.display  :  x.vindovs. display; 
the.windov  :  x.vindovs . window)  return  vidget; 


--  handling  errors 


function  xt.app.get.error.database 

(app.context  :  application.context)  return  x.vindovs. xrm_database; 


procedure  xt.app_get_error.database.text 

(app.context  :  application.context; 

name,  restype,  class  :  string; 

default  :  string; 

buffer.return  :  in  out  string; 

database  :  x.vindovs. xrm.database) ; 


procedure  xt.app.set.error.msg.handler 
(app.context  :  application.context; 
msg.handler  :  xt_error_msg.handler.proc) ; 

procedure  xt.app.error.msg  (app.context  :  application.context; 

name,  restype,  class,  default  :  string; 
params  :  in  out  string.list) ; 


procedure  xt.app.set.warning.msg.handler 
(app.context  :  application.context; 
msg.handler  :  xt_error_msg.handler.proc); 

procedure  xt.app.vaming.msg  (app.context  ;  application.context; 

name,  restype,  class,  default  :  string; 
params  :  in  out  string.list); 

procedure  xt.app.set.error.handler 

(app.context  :  application.context; 
handler  ;  xt.error_handler.proc) ; 


procedure  xt.app.error  (app.context 

message 


appli cation. context ; 
string); 


procedure  xt.app.set.varning.handler 
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(app. context  :  application.context : 
handler  :  xt_error.handler.proc); 


procedure  xt.app. warning  (app.context 

message 


:  application.context ; 
:  itring) ; 


end  xt .utilities; 


The  following  procedure  types  are  defined  for  use  by  the  utilities: 
pseudo.type  xt.convert.seleetion.proc  is 


new  proc.type (the.widget 
selection 
target 
type.retum 
value.retum 
length.return 
format .ret urn 


widget 

x.windows . atom; 

x_ windows. atom; 

x.windows .atom; 

out  x.windows .caddr.t; 

out  cardinal; 

out  x.windows .x.integer) 

return  boolean; 


pseudo.type  xt.lose.seleetion.proc  is 

new  proc.type (the .widget  :  in  out  widget; 

selection  :  in  out  x.windows. atom; 
target  :  in  out  x.windows. atom) ; 

pseudo.type  xt.selection_callback.proc  is 

new  proc.type (the.widget  :  in  out  widget; 

client .data  :  in  x.windows .caddr.t; 
selection  :  in  out  x.windows . atom; 

selection.type  :  in  x.windows . atom; 
value  :  x.windows . caddr.t ; 

length  :  in  cardinal); 

pseudo.type  xt.error_msg_handler.proc  is 

new  proc.type (resource.name  :  string; 

resource.type  :  string; 
resource.elass  :  string; 
default.p  :  string; 

params  :  string.list) ; 

pseudo.type  xt.error_handler.proc  is 

new  proc.type (message  :  string); 
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5  Appendix  A:  Case- Statement  Procedure  Types 

with  system;  us*  system; 
package  body  callback. mechanism  is 

type  callback.mapped.id  is 

range  callback.id.range' first  ..  callback.id.range 'last  •  VUK.CALLBACKS ; 

unmapped. id:  constant  callback.upped.id:*  callback .mapped. id' first; 

callback.id.map  :  array ( callback. id.range)  of  callback.mapped.id:- 
(others  «>  nnmapped.id) ; 

starting.at:  callback.mapped.id:*  callback.mapped.id’ first  ♦  1; 
next .aiapped. id:  callback.mapped.id :=  starting.at; 

package  body  callback.ids  is 

next. id:  callback.id.range:*  callback. id. range' first  ♦  1; 

—  return  a  unique  callback  id 

function  next.callback.id  return  callback.id.range  is 
i:  callback.id.range:*  next. id; 
begin 

next.id:*  next.id  ♦  1; 
return  i; 
exception 

when  constraint. error  ■> 

raise  CALLBACK.RAIGE.ERROR; 
end  next.callback.id; 

--  select  the  callback  id  from  the  callback  object 
function  to_callback_id_range(id:  callback.id.type) 
return  callback.id.range  is 
begin 

return  id.the.callback.id; 
end  to.callback.id.range; 

end  callback.ids; 


—  these  procedures  should  never  be  called,  so  raise  exception 
procedure  def ault_next_call.back(id:  callback.id.type;  s:  string)  is 
begin 

raise  CALLBACK .CALL.ERROR; 
end; 

procedure  default_callback(s :  string)  is 
begin 

raise  CALLBACK.CALL.ERROR; 
end  default.callback; 
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package  body  callbacks  is 

—  aacb  instantiation  of  callbacks  has  a  distinct  id  rang* 

low, range,  high .rang*:  callback.mapped.id: ■  callback.mapped.id’ last; 

procadura  callback  (id  :  callback. id.type;  s:  string)  is 
—  subtype  assignment  allows  use  of  case  statement 

subtype  callback.range  is  callbaek.mapped.id  range  1  ..  IUH.CALLBACKS ; 
upped. id:  callbaek.mapped.id:* 

callback_id_map(to_callback_id_range(id)) ; 
index:  callback.range; 
begin 

if  mapped. id  in  low.range  . .  high. range  then 
index:*  mapped.id  -  low.range  *  1; 
case  index  is 

when  1  ■>  cbl(s);  —  call  the  actual  callback 
when  2  ■>  cb2(s); 
whan  3  •>  cbS(s); 

end  ease; 

else  —  in  the  range  of  a  previous  instantiation 
next_callback(id,  s); 
end  if; 
end  callback; 


begin  —  initialize 

low.range:*  starting.at; 

high.range:*  low.range  ♦  IUH.CALLBACKS  -  1; 
starting.at:*  high.range  ♦  1; 


—  do  this  if  . .  then  code  for  each  formal  callback 
if  cbl* address  /-  default .callback' address  then 
if  idl  /*  null. id  then 

if  callback.id  mapCto.callback.id.range(idl))  /-  unmapped.id  then 
raise  CALLBACK.IISTALL.ERROR;  —  valid  procedure,  duplicate  id 

else 

callback_id_map(to.callback.id_range(idl)) :«  next .mapped. id; 
end  if; 

else  „„  ^ 

raise  CALLBACK. IIST ALL .ERROR ;  —  valid  procedure,  null  id 

end  if; 
end  if; 

next.mapped.id:*  next .mapped. id  ♦  i; 


if 


cb2’ address  /*  default.callback' address  then 

if  id2  /■  null. id  then  ...... 

if  callback  id  map(to.eallback_id_range(id2))  /*  unmapped.id  then 
raise  CALLBACK.IISTALL.ERROR;  —  valid  procedure,  duplicate  id 

*llcallback_id_map(to_callback_id.range(id2)) :*  next.mapped.id; 
end  if; 

else  .. 

raise  CALLBACK.IISTALL.ERROR;  —  valid  procedure,  null  id 

end  if; 
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•nd  if; 

naxt.nappad.id:*  naxt.mappad.id  ♦  1; 

if  cb3’addrass  /*  dafault .callback' addrass  then 
if  id3  /■  null. id  than 

if  callback.id_nap(to_callbaek.id_ranga(id3))  /■  unmappad.id  than 
rail#  CALLBACK. IISTALL.ERROR;  —  valid  procadura,  duplicata  id 

alaa 

callback_id_n&p(to.callback_id_ranga(id3)) :■  naxt.nappad.id; 
and  if; 

alaa 

raisa  CALLBACK. IISTALL.ERROR;  --  valid  procadura,  null  id 
and  if; 
and  if; 

naxt.nappad.id:*  naxt.nappad.id  ♦  1; 
and  callbacks; 


and  callback.nachanisn; 
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6  Appendix  B:  System-Dependent  Procedure  Types 


package  body  xt.procedure.types  if 
package  body  xt.widget.elass.procs  is 


—  private  data  and  functions 

bad.procedure.reference  :  exception; 

xt.inherit.constant.record  :  xt.widget.class.proc.rep; 
xt.inherit.constant  :  xt.widget.class.proc; 

—  arg.record  is  a  record  encapsulation  lor  arguments  to  ada 

—  functions.  Encapsulating  as  a  record  permits  us  to  write 

—  exactly  one  foreign  language  dispatcher,  which  will  call 

--  an  intermediary  Ida  subprogram  by  pointer  which  will  in  turn 

—  call  the  Ada  subprogram  of  an  arbitrary  parameter  profile. 

type  arg.record  is  record 

the.widget.class  :  widget. elass; 

—  other  parameters  to  the  call  function  go  here... 
end  record; 

type  arg.record.pointer  is  access  arg.record; 


arg.record.buff er 


arg.record;  —  global  arg.record  for  use  as 

—  argument  passing  vehicle.  Could 
--  also  make  local  to  procedure  call, 

—  but  then  would  be  on  stack.  Xs 

—  that  better  or  worse? 


procedure  del ault.xt .widget. class_proc(the.widget_class  :  widget.class)  is 
begin 

raise  bad.procedure.referenee; 
end; 


—  type  converters  for  converting  to/from  system. address 

function  address.to. arg.record.pointer  is 
new  unchecked. conversion( 

source  «>  system. address,  target  ■>  arg.record.pointer); 

function  xt.widget.class.proc.to.address  is 
new  unchecked.conversionC 

source  ■>  xt.widget.class.proc, 
target  *>  system. address) ; 

—  visible  functions 

function  xt.inherit_widget_class.proc  return  xt.widget.class.proc  is 
begin 
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return  xt.inherit.constant; 

•nd; 

procedure  call( 

the.proc.id  :  zt .widget .class .pro c;  the.widget.elast  :  widget.clasB)  is 
begin 


—  construct  the  argument  patting  buffer 
arg.record.buffer .the.widget.elast  :■  the.widget.elast; 

—  call  the  C  or  assembler  or  ...  routine  which  calls  the  function 
dispatch.interf aces . call.adaC 

xt.widget.class.proe.to.address (the.proc.id) , 
arg.record.buffer' address) ; 

end; 

package  body  proeedure.pointer  is 

—  procedure  intermediary. caller  is  the  actual  subprogram  which 

--  invokes  the  user  supplied  function.  The  address  of  intermediary.caller 

—  is  put  into  the  id  returned  by  the  instantiation. 

procedure  intermediary. callerC 

—  the.proc.id  :  zt.widget.class.proc; 
arg.record.address  :  system. address)  is 

an.arg.record.pointer  :  arg.record.pointer  :• 

address_to_arg_record_pointer(arg_record_address) ; 

begin 

—  "the.proc"  is  the  generic  procedure 
the.proc (an.arg.record.pointer .the.widget.elast) ; 

end; 

begin 

—  Tads  version  does  not  need  to  save  context  information 

—  for  intermediary.caller 
declare 

temp_zt.widget_class_proc.rep  :  xt.widget_class_proc.rep; 
begin 

dispatch.interf aces . save.environment.context ( 
temp.zt_widget_class_proc.rep’ address) ; 
temp_xt_widget_class_proc_rep.proc_address  :  = 
intermediary.caller ’ address ; 
proc.id  :* 

new  zt.widget.class.proc.rep’ (temp_zt_widget.class.proc. rep) ; 

end; 

end  proeedure.pointer; 
begin 

zt .inherit .constant. record. proc. address  : ■ 
zt _ inherit. widget. class.proc’ address; 
zt.inherit.constant  :■ 
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new  xt .widget. class.proc.rep ’ (xtr~inherit_constant_record) ; 
•nd  xt .widget. class.procs; 

—  other  procedure  type  package! . . . 

end  xt.procedure.types; 


with  system;  use  system; 
package  dispatch.interfaces  is 

—  Dispatch.interfaces  provides  the  entries  for  assembler  or  C  or  ... 

—  code  which  saves  subrogram  environment  data  and  invokes  Ada  subprograms 

—  via  their  address. 

procedure  call.ada ( 

the.proc.deseriptor  :  system. address; 
the.arg.descriptor  :  system. address); 

pragma  interface  (  C,  call.ada  ); 

procedure  save.environment. context (the.proc.deseriptor  :  system. address ) ; 
pragma  interface  (C,  save.environment.context) ; 
end  dispatch.interfaces; 


/*  the  C  code  for  VADS,  TeleSoft,  and  Tartan,  which  invokes  the  subprograms 
via  their  addresses  */ 


typedef  void  (*Proc)(); 
typedef  struct  .proc.descriptor  { 

Proc  p; 

/* 

ALSYS  data  fields 
int  gd; 
int  teb; 
int  profile; 

*/ 

}  ProcDescriptorRec,  eProcDescxiptor; 


void  call_ada(pd,  arg) 

ProcDescriptor  pd; 
char  *arg; 

/*  Alsys  version  of  call.ada  is  assembler  which  restores  subprogram 

environment  context,  and  passes  the  argument  via  the  data  register  dO. 
For  VADS,  etc.,  the  call  stack  is  used  to  pass  arguments,  and 
a  simple  JSR  will  suffice.  */ 

(*(pd->p))(arg) ; 

> 
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▼oid  *ava_anvironmant .context (pd) 

ProcD«»criptor  pd; 

/*  null  body  lor  VADS,  TalaSoft,  and  Tartan.  */ 

> 
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7  Appendix  C:  Simple  Widget  Definition 


Simple  Widget:  Public  Pseudo-Type 

with  Intrinsic! ;  ns*  intrinsic!; 
with  cor*_public;  ns*  core.public; 
pragma  *laborat* (intrinsic*) ; 
package  simple.public  is 

—  1)  r*sourc*s  documentation: 

Default  Value 


It Default Background 
ZtDefaultForeground 
1 

■on* 

TOLL 

0 

Gray 

True 

True 

0 

0 

0 


—  lame 


background 

border 

borderVidtb 

cursor 

destroyCallback 

height 

ins  ens it i veBorder 

mappedVhenManaged 

sensitive 

width 

x 

7 


Class 

Background 

BorderColor 

BorderVidth 

Cursor 

Callback 

Height 

Insensitive 

MappedVhenManaged 

Sensitive 

Vidth 

Position 

Position 


RepTyp* 

Pixel 

Pixel 

Dimension 

Cursor 

Pointer 

Dimension 

Pixmap 

Boolean 

Boolean 

Dimension 

Position 

Position 


—  2)  define  constants  for  new  resources.  Can  w*  us*  enumeration  and  'image? 

xt.n.cursor  :  constant  string  :•  "cursor"; 

xt.c. cursor  :  constant  string  :•  "Cursor"; 

xt.n. insens it ive.border  :  constant  string  : ■  "insensitive.border" ; 

xt.c.insensitive.border  :  constant  string  : ■  "Insensitive"; 

—  3)  define  application  interface  to  types  and  constants  for  intrisics  use: 

subtype  simple. widget  is  core.widget; 
subtype  simple.class  is  core.class; 

function  the.simpl*. class  return  simple.class; 

—  3a)  define  application  type  conversion  operations 


—  4)  define  public  entries  to  simple.widget  operations: 
procedure  foo(s  :  simple.widget);  —  demonstration  only 
—  I0IE 


end  simple.public; 
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Simple  Widget:  Private  Actual- Type 

with  intrinsic! ;  ns*  intrinsic!; 
with  renamed.xlib.types ;  ns*  renamed.xlib.types; 
with  x_ windows; 
with  system; 

with  compiler .dependent; 
with  unchecked.conversion; 

—  superclass  context 

with  core.private;  ns*  cor* .private; 

package  simple .private  is 

ns*  xt.ancillary .types; 

ns*  xt.procedure.types .xt.realize.procs ; 

us*  xt. geometry .management; 

ns*  xt.resource.management; 

us*  xt.translation.management; 

simple .part .rec.siz*  :  constant  cardinal  :■  64; 
type  simple .part _r*c  is  record 

the.cursor  :  x.windows. cursors. cursor; 
insensitive.border  :  x_ windows. pixmap; 
end  record; 

eimple.widget.siz*  :  constant  cardinal  ;■ 
core .part .size  +  simple. part .rec.size; 
type  simple.widget.rec  is  record 

core.part  :  core.private. cor# .part ; 
simple.part  :  simple.paxt.rec; 
end  record; 

tor  simple.widget.rec  us*  record  at  mod  2;  —  alsys  requires  "2" 
core.part 
at  0 

rang*  0  ..  core.part.siz*  -  1; 

simple.part 

at  0 

rang*  core.part.siz*  ..  core.part.siz*  *  simple.part .rec.siz*  -  1; 
end  record; 

type  simple.part.pointer  is  access  simple.part.rec; 
type  simple.widget .pointer  is  access  simple.widget.rec; 

simple_class_part.rec.siz*  :  constant  cardinal  :■  32; 
type  simple_class.part.rec  is  record 

is.change.sensitiv*  :  xt.realize.proc; 
end  record; 
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core.class.part  :  cora_priTata.cexa_clatg.part; 
simple.class.part  :  simple.elass.part.rec; 
and  r a cord; 

for  simple.class.part  use  racord  at  mod  2; 
coxa  _  clat  t .part 
at  0 

range  0  ..  core.clagg.part.tize  -  1; 

simple.class.part 

at  0 

range  cora.clatt.part.tiza  . . 

cora.clast.part.tiza  +  timpla.clagg.part.rac.tiza  -  1; 
and  racord; 

type  gimpla.claas .part .pointer  ia  access  simple. class.part.rac; 
type  gimple.class.pointer  it  access  gimpla.class.part ; 

—  allocate  the  clast  conitant 

function  to.widget.class  it  ne«  uneheeked.eonversionC 
source  •>  a imple.class .pointer , 
target  ■>  widget. class) ; 

the.simple. clast  :  constant  widget.clats  :■ 
to.widget. class  (new  simple.clast.part) ; 

end  simple.priTate; 
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Simple  Widget:  Public  Pseudo-Type  Implementation 

—  superclass  context 

with  core .public;  use  core.public; 
with  simple.private;  use  simple.private; 

with  x.windows;  use  x.windows; 
with  unehecked.conversion; 
with  system; 

with  renamed.xlib. types;  use  renamed.xlib.types; 
with  compiler.dependent ; 
with  text.io; 

pragma  elaborate  (simple.private) ; 
pragma  elaborate  (core.public) ; 
pragma  elaborate  ( compiler .dependent ) ; 

pragma  elaborate (text.io) ; 

package  body  simple.public  is 

use  xt.ancillary .types; 

«*•  xt.procedure.types.xt.widget.elass.procs; 

use  resource.manager; 

—  type  conversion  operations: 

function  to.simple.class  is  new  unchecked_conversion( 
source  ■>  simple.class.pointer , 
target  ->  single .class) ; 

function  to.simple.widget.pointer  is  new  unehecked.conYersion( 
source  ->  simple.widget, 
target  •>  simple.widget .pointer) ; 

function  to.simple.class.pointer  is  new  unchecked_conversion( 
source  »>  widget.class, 
target  ■>  simple.class.pointer) ; 

—  global  objects: 

init.proc  :  xt .widget. class.proc; 

simple. class.constant  :  constant  simple.class.pointer  :■ 

to.simple.class.pointer  (simple_private.the_simple.dass) ; 


—  procedures  for  the  class  structure: 

procedure  simple_class_part_initialize(wc  :  widget.class)  is 
begin 

text.io. put.line ("simple  class  class  part  initialization"); 
end; 


—  visibile  operations: 
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function  the.simple.class  return  simple.class  is 
begin 

return  simple. class  (simple .private. the. simple. class); 
end; 


procedure  foo(*  :  simple.vidget)  is 

spp  :  simple.sidget .pointer  :■  to.simple_«idget.pointer(v) ; 
begin 

spp.core.part.managed  :■  xt_ancillary_types.xt.true; 
end; 


begin 

declare 

--  procedure  Instantiations: 

package  init.proes  is  new  procedure. pointer( 

proc.id  •>  init.proc, 

the.proc  ■>  simple. class.paxt. initialise  ); 
begin 

simple. class. constant. all  : ■  ( 
core.class.part  »>  ( 

superclass  ■>  core_public.the_core.dass, 
class.name  ■>  null, 
vidget.size  «>  simple.vidget. size, 
class. initialize  ■>  null, 

class.part. initialize  ■>  init.proc,  --  non-def suited 

class.inited  ■>  xt .false, 

initialize  ■>  null, 

initialize .hook  ■>  null, 

realize  ■>  null, 

actions  ■>  null, 

resouxcesc>  null, 

the_xrm_classs>  xrm. class' first, 

compress.motion  *>  xt.false, 

compress.exposure  *>  xt.false, 

compress.interleave  «>  xt.false, 

visible.interest  »>  xt.true, 

destroy  ■>  null, 

resize  *>  null, 

expose  «>  null, 

set.values  «=>  null, 

set.values.hook  ■>  null, 

set.values.almost  ■>  null, 

get.values.hook  =>  null, 

accept .focus  *>  null,  this  should  be  e.func 
version  ■>  xt.version.type' first, 
callback.private  ■>  null, 
tm.table  *>  null, 

query .geometry  «>  null,  ~~  should  be  e.func 


25  January  1990 


STAK5-K<~-m  UUU/UUl/UU 


7  APPENDIX  C:  SIMPLE  WIDGET  DEFINITION 


86 


display.accalarator  *>  null-, 

•ztansion  ■>  caddr_t( compiler _d«p*nd«nt .null.addraas)  ), 
■iapla.clasa.part  »>  ( 

ia.changa.aansitiva  ■>  null  )); 

and; 

and  sinpla.public; 
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